TS/MP 2.5 Pathsend and Server Programming Manual

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 requestor can commit the transaction. In the second case, the requestor 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 must 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 requestor can end it—but it ensures that the transaction
is aborted. The requestor must then call either ABORTTRANSACTION or ENDTRANSACTION after
it replies to the server. (If the requestor 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 must 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 must 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 requestor,
which has been replied to prematurely, sends one more request to the server and the server increases
its potential queue by one request. A single-threaded server queue can result in poorer performance
for the application system.
Audited and Nonaudited Servers
If your Pathway application uses a database that is a combination of TMF audited files and
nonaudited files, write separate servers to process the two types of files. Updates to audited files
must occur within a TMF transaction; updates to nonaudited files must not occur within a transaction,
because the transaction imposes unnecessary overhead.
Use of a GDSX Back-End Process
The GDSX communications subsystem product, described under “Requestors Using GDSX” (page 39),
earlier in this chapter, can also be used as a back-end process for Pathway server-classes.
A GDSX back-end process receives input from multiple processes on a NonStop system and provides
access to a limited number of I/O devices. Common uses of GDSX back-end processes include
implementing communications protocols; message switching; and coordinating access to shared
resources or I/O devices, such as log files, terminals, or remote ports.
In a back-end process, each thread of the device handler has no direct association with an I/O
device. Figure 8 (page 46) shows a typical message-switching application in which processes on
the NonStop system send messages to the communications process on the remote system. Here,
the GDSX process might run a line-handler task to handle data on the communications lines and
Designing Server Programs 45