TMF Application Programmer's Guide (G06.24+)

Designing Single-Threaded Processes
HP NonStop TMF Application Programmer’s Guide—522419-004
2-15
Guarantees to Servers
transactions have been aborted, the requesters open a new instance of the failed
server and then restart each transaction from the beginning.
As a result of this fundamental design characteristic of TMF, the processing of a failed
server simply cannot be taken over in midstream by a backup process, and the use of
checkpoints within a server is therefore meaningless.
Guarantees to Servers
TMF makes the following guarantees to server processes:
•
Until the server issues a reply to the requester, the current transaction is not
committed.
•
All changes that a server has made to the database prior to issuing a reply
participate in the eventual outcome of the transaction; the changes are either
committed or backed out.
•
If the server issues an ABORTTRANSACTION call, the current transaction
unconditionally aborts and all changes made by anyone to the database on behalf
of the aborted transaction are backed out.
•
If a nonrecoverable hardware or software failure occurs while the server is working
on the transaction, the transaction is unconditionally aborted and all changes made
to the database on behalf of the aborted transaction are backed out.
Context-Sensitive Servers
Some TMF users have designed their applications to include multiple-message
communication between a requester process and a particular server process. In that
environment, the server process must maintain the context of a transaction throughout
the interval spanned by successive interprocess messages. This type of server
process is referred to as, “context-sensitive.” The use of context-sensitive servers
requires that the requester observe certain constraints that can only be guaranteed
through proper application design; TMF does not support this type of operation and
cannot enforce the associated rules.
Suppose, for example, that a requester and server need to perform a transaction that
requires five WRITEREAD-REPLY sequences. If fewer than all five sequences are
performed, the transaction is not complete. According to the standard TMF rules, each
time the server issues a reply, the server process is implicitly agreeing that the
transaction can be committed. In a context-sensitive environment, however, that is true
only for the final reply in the sequence.
A properly designed and coded requester ensures that the transaction gets aborted if
anything prevents the completion of all five WRITEREAD-REPLY pairs. This includes a
mechanism to detect a failure of the server process prior to the fifth reply, in which
case the requester aborts the transaction, starts a new server using the old server’s
name, and then restarts the entire transaction.