TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-23
Design Considerations
•
Single-threaded servers that send to other server classes can cause low server
utilization in the same way that any single-threaded process that calls another
process can: the server process sending the request is idle until it receives a reply
from the server to which it sent the request.
•
Single-threaded servers that send to other server classes can, therefore, result in
longer queues for a server class, and these longer queues can affect application
performance.
Aborting Transactions
A request sent to the server can have one of three outcomes:
•
All the work for the request was completed successfully.
•
None of the work for the request was completed.
•
The work for the request was only partially completed.
In the first case, the requester can commit the transaction. In the second case, the
requester can commit the transaction and then retry it. In both of these cases, the
information in the server’s reply is sufficient to ensure the integrity of the transaction.
However, if the transaction work was only partially completed, as in the third case, the
server needs to ensure that the transaction is not committed, so that the incomplete work
can be backed out. To ensure transaction backout, the server should call the
ABORTTRANSACTION procedure after it reads the server’s request and before it sends
its reply. A call to ABORTTRANSACTION by the server does not end the transaction—
only the requester can end it—but it ensures that the transaction is aborted. The
requester should then call either ABORTTRANSACTION or ENDTRANSACTION
after it replies to the server. (If the requester calls ENDTRANSACTION in this
situation, the ENDTRANSACTION call returns an error because the transaction has
already been aborted. However, either call ensures that the resources associated with the
transaction are released.)
Fault-Tolerant Process Pairs
You should not write your server processes as fault-tolerant process pairs when you are
using the TMF subsystem to protect transactions. The additional programming and
functional overhead required to do so is unnecessary.
Early Replies
You should program your servers so that when a server process reads a request message,
it completely processes the request before it replies to it. This practice is often called the
no-early-reply rule. If you do not follow this rule, the server process loses the TMF
transaction identifier it requires to finish processing a transaction. After the reply, any
further attempts to lock, write, or delete records in the same audited files will fail. In
addition, failure to follow the no-early-reply rule can create a queue of incomplete
transactions for single-threaded servers. The queue occurs when the requester, which has
been replied to prematurely, sends one more request to the server and the server