TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

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 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 should 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 “Requesters Using GDSX” (page 40),
earlier in this section, 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 47) shows a typical message-switching application in which processes on
the NonStop system send messages to the communications process on the remote system. Here,
46 Designing Your Application