hp Reliable Transaction Router
C Application Programmer's
Reference Manual

To build on UNIX, issue the command:

cc -o server adg_server.c adg_shared.c /usr/shlib/librtr.so -DUNIX

You should start the servers before you start your clients. They will register with the RTR router so that the router will know where to send client requests. Start your primary server with the appropriate ‘run’ command for its operating system along with the two parameters ‘1’ and ‘h’. To run on UNIX:

% 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 that 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 Reliable Transaction Router Application Design Guide. Then, earlier sections of this manual will tell you in detail how to implement each capability.

Training Services offers training classes for RTR. If you’d like to attend any of them, contact your local 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 are 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 for RTR to 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. So as you can see, if your database and transactions are important enough to you, you have the opportunity to double protect them with an RTR configuration that includes some of the following:

• A standby software server 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 backends
• Failover routers
• Concurrent servers

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.