Availability Guide for Application Design

Availability in the Pathway Transaction-Processing
Environment
Availability Guide for Application Design—525637-004
6-23
Design Implications for Pathsend Requesters
Nonretryable requests that are not protected by TMF cannot be processed more than
once without adverse effects. An example of this kind of request is a request to
subtract $50.00 from a bank account balance. For these requests, there is no way for
the server class to detect duplicate requests; Pathsend does not support checkpointing
of synchronization identifiers. Therefore, the backup process cannot send the request
again, because the operation might be processed more than once. Because the
request cannot be safely retried, the Pathsend process cannot ensure that the request
gets processed.
Design Implications for Pathsend Requesters
While a degree of availability is provided by TMF, additional effort is required by either
the application developers or operations staff to keep Pathsend applications available.
Development Concerns
Consider the following development concerns when designing a Pathsend application:
•
Decide on the level of persistence required by your requester processes.
Depending on your business needs, you must decide how much delay is
acceptable following a failure, and how much reentry of data is acceptable. Higher
levels of persistence often require more effort to develop and test.
•
Consider which operations are retryable and which are not.
•
If you choose to use process pairs with continual checkpointing, use care when
placing your checkpoints. The primary requester process must checkpoint enough
information to get the backup process and the outstanding transaction restarted.
This information should include:
•
Status information that tells the new primary process whether a transaction
was outstanding at the time of the failure
•
Enough data to be able to restart the transaction
•
Decide whether your requester will be multithreaded or single-threaded. If your
application needs to service several devices, you might choose to write your
requester as a multithreaded process. Such processes are complex to develop as
process pairs but can run more efficiently than multiple single-threaded processes
because of the reduced overhead of having fewer processes to manage.
•
Ensure that your Pathsend requester process is coded with adequate error-
handling capabilities. Refer to Section 9, Minimizing Programming Errors, for
general information on error handling.
For details on developing single-threaded and multithreaded processes that use the
TMF procedure calls, refer to the TMF Application Programmer’s Guide. For details on
using the Pathsend interface, refer to the NonStop TS/MP Pathsend and Server
Programming Manual.