Availability Guide for Application Design

Availability in the Pathway Transaction-Processing
Environment
Availability Guide for Application Design—525637-004
6-22
Availability of Pathsend Applications
transactions are backed out. The application remains available, but the end user must
be made aware of the failure and from what point to start reentering data.
Requester Process With Initialized Persistence
A requester process that runs as a process pair with initialized persistence can take
over in its backup process if the primary process fails. Operations protected by
transactions are backed out. The requester process does not start from the beginning
but in a preinitialized state. The end user must be made aware of the failure and from
what point to start reentering data as for the immediate persistence case. Using
initialized persistence, however, takeover is faster than immediate persistence
because you save the initialization time.
Process-Pair Requester With Continual Checkpointing
For the requester to be always available, it must run as a process pair. If the primary
requester process fails, then the backup requester process running in a different
processor can take over processing. Availability is achieved in a different way,
depending on whether the requester encloses input/output requests to the server
within TMF transaction boundaries.
Requests Protected by TMF Transactions
For Pathsend calls that are protected by the TMF product, upon takeover, the new
primary requester process must determine whether the current transaction ended or
aborted. It does this through status information checkpointed by the old primary
requester process. If the transaction aborted, the new primary requester can retry the
entire transaction. The backup requester begins a new TMF transaction and reissues
the Pathsend calls.
In a typical Pathsend requester that runs as a process pair, you must use care in
choosing what you checkpoint and where you place those checkpoints. Checkpointing
is usually done only at the beginning and end of the transaction. The checkpoint at the
beginning saves the transaction context in case it has to be restarted. The checkpoint
at the end updates the transaction status. Checkpointing I/O operations within a
transaction is meaningless since the transaction would be replayed in case of failure.
Incorrectly placed checkpoints can cause errors or even data corruption.
Requests Not Protected by TMF Transactions
For Pathsend calls not protected by TMF, the proper recovery depends on whether the
request is retryable. Retryable requests that are not protected by TMF can be repeated
many times without adverse effect. An example of this kind of request is to read a bank
balance. Requests to retrieve data from a database are retryable requests. For these
requests, on backup takeover, the backup can simply reissue the request. The request
could be processed more than once by different server processes without resulting in
data corruption. Different, yet correct answers could be returned on the retry if the bank
balance meanwhile changed because, for example, a check was cleared.