Reliable Transaction Router
C Application Programmer's
Reference Manual

% server 1 h

Start your standby server with the parameters ‘2’ and ‘h’.

% server 2 h

Build and Run the Client:
Compile the ADG_CLIENT.C and ADG_SHARED.C module on the operating system which will run your client application.

To build on UNIX:

% cc -o client adg_client.c adg_shared.c /usr/shlib/librtr.so -DUNIX

Run the client with the following command:

% client 1 h 10

or

C:\RtrTutor\> client.exe 1 h 10

But Wait! There’s More!
This tutorial has only scratched the surface of RTR. There is a great deal more that RTR gives you to make your distributed application reliable, available, and perform better.

The following sections of this document highlight some of the capabilities you have at your service. For more details on each item, and information on what additional features will help you to enhance your application, look first through the RTR Application Design Guide. Then, earlier sections of the RTR Application Programmer’s Reference Manual will tell you in detail how to implement each capability.

Compaq Computer Corporation also offers training classes for RTR, and if you’d like to attend any of them, contact your Compaq representative.

Callout Server:
RTR supports the concept of a "callout server" for authentication. You may designate an additional application on your server machines or your router machine as a callout server when it opens its channel to the router. Callout servers will be asked to check all requests in a facility, and are asked to vote on every transaction.

Events:
In addition to messages, RTR can be used to dispatch asynchronous events on servers and clients. A callback function in the user’s server and client applications can be designated which RTR will call asynchronously to dispatch events to your application.

Shadowing:
This tutorial only discussed failover to a standby server. But RTR also supports shadowing: while your server is making changes to your database, another "shadow" server can be making changes to an exact copy of your database in real time. If your primary server fails, your shadow server will take over, and record all of the transactions occurring while your primary server is down. Your primary server will be given the opportunity to update the original database and catch up to the correct state when it comes back up.

Primary and secondary shadow server can also have standby servers for failover! So as you can see, if your database and transactions are important enough to you, you have the opportunity to double and triple protect them with an RTR configuration including any of

• multiple standby software servers on a primary hardware backend system
• a shadow backend system replicating all transactions on a duplicate database
• failover backend systems for each of your primary and shadow backends
• failover routers

Transactions:
One of RTR’s greatest strengths is in supporting transactions. The RTR Application Design Guide goes into more detail regarding transactions and processing of transactions.

RTR Utility:
You’ve seen how to use the RTR utility (or CLI) to start RTR and to create a facility. But the RTR utility contains many more features than this, and in fact can be used to prototype an application. Refer to the RTR System Manager’s Manual for details.