TMF Application Programmer's Guide (H06.06+, J06.03+)

Designing Multithreaded Processes
HP NonStop TMF Application Programmer’s Guide—540139-009
3-4
Checkpointing Strategy
The sample requester responds to all error conditions by aborting the transaction and
refreshing the READ to the affected terminal. The requester does not try to determine
what type of error occurred or to make any decisions based on the error condition.
Individual Threads
As illustrated in Figure 3-1, the sequence of activities in a multithreaded requester is
basically the same as that of a TMF transaction in a single-threaded requester. The
major difference is that each thread in a multithreaded environment uses nowait
procedure calls and, as a result, spends more time in a suspended state as the
requester works on other concurrent transactions (threads).
The requester divides each thread into pieces, with each piece roughly corresponding
to those sets of activities in Figure 3-1 that lie between the gray SUSPEND boxes. The
requester does this asynchronously, essentially on a first come, first served basis;
when an AWAITIO call completes, the requester uses filenumber and tag to
determine what type of call completed and which transaction (thread) the completion is
associated with. The requester then resumes processing for the particular transaction
until the next point of suspension.
At any given time, only one thread is active; all others are temporarily suspended.
Furthermore, each thread is at a particular point in its processing that is completely
independent of all other threads. Within the requester itself, the threads have little
impact on one another. Any contention between the threads occurs at the server level,
where one transaction might have to wait momentarily for another transaction’s locks
to be released.
Placement of Checkpoints
Figure 3-2 and Figure 3-3 together illustrate the flow of control within a primary
multithreaded TMF requester process. Figure 3-2 shows the overall flow while
Figure 3-3
shows the detailed functionality within each logical block of code.
Within the life of a transaction, there are three places at which information must be
checkpointed:
1. Along with BEGINTRANSACTION, the primary process must issue a
CHECKPOINT call to pass all application data necessary to restart the transaction
to the backup process.
2. After BEGINTRANSACTION, and before issuing the corresponding
ENDTRANSACTION call, the primary process must call CHECKPOINT to
generate an entry for that transaction in the backup requester’s TFILE.
3. After either ENDTRANSACTION or ABORTTRANSACTION, the primary process
must call CHECKPOINT to flush the transaction’s entry from the backup
requester’s TFILE.
By properly placing your CHECKPOINT calls, however, you can actually accomplish all
three of these checkpoint operations with just two calls.