Availability Guide for Application Design

Availability in the Pathway Transaction-Processing
Environment
Availability Guide for Application Design—525637-004
6-17
Design Implications for RSC/MP Applications
Coding Transactions and Saving Context for Availability
To make failure recovery possible, your client program must do the following during
normal operation:
•
Protect all server requests that cannot be retried with TMF transactions. These are
the types of requests that cannot be processed more than once without adverse
effects; for example, withdrawing a sum of money from a bank account.
•
Save all the context you need to begin the transaction so that the transaction can
be restarted.
•
Save all data and state information used by the transaction so that it can be
replayed, if necessary, without the user entering the data again.
•
Check for connection errors on all RSC/MP calls within the transaction, including
the call to commit the transaction.
•
Save any configuration information associated with establishing a connection or a
session.
Coding the Client for Failure Recovery
By checking the return value of RSC/MP calls, your client process can determine
whether a connection error has occurred. Your program should include the following
logic to recover:
1. Inform the user that a communications failure has occurred and that recovery is in
progress.
2. Use the saved connection configuration data to attempt to reconnect to the TDP.
The TDP might not be immediately available. Therefore your code should be
prepared to repeat the attempt to reconnect several times over a period of,
perhaps, 30 seconds to a minute. If desired, you can periodically inform the user
that recovery is still in progress or inform the user of the number of retries.
3. Once the connection is reestablished, use the saved session configuration
information to establish a new session.
4. If notification of the failure was returned by an attempt to commit a transaction,
check the database to determine whether the transaction committed. Because the
transaction is managed on behalf of the TDP (not the client process), it is possible
that the failure occurred after TMF committed the transaction on the server but
before the TDP had the chance to return the confirmation to the client. A
connection error on the transaction commit call is therefore not enough to
determine whether the transaction committed or aborted.
5. If a transaction was in progress at the time of the failure, use the saved transaction
context to restart and replay the transaction.
6. Inform the user that the connection-failure recovery is successfully finished.