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

Designing Multithreaded Processes

HP NonStop TMF Application Programmer’s Guide—522419-005

3-14

Multithreaded Requester/Server Processes

You can design program modules that simultaneously act as a multithreaded requester

for some transactions and as a multithreaded server for others.

These kinds of program modules must open both a TFILE and a $RECEIVE pseudofile

(with options greater than 1 for the TFILE and receive-depth greater than 1 for

$RECEIVE), but still have only one current transaction.

The TFILE options and $RECEIVE receive-depth parameters are completely

independent of one another.

The TFILE options parameter specifies the maximum number of new transactions

the program module can initiate (if the TFILE is opened with an options parameter

of four, for example, the program module can issue up to four BEGINTRANSACTION

calls without first issuing an ENDTRANSACTION or ABORTTRANSACTION call).

The $RECEIVE receive-depth parameter specifies the maximum number of

transaction identifiers the program module can inherit from requester modules.

At any given time, the current transaction specifies one of the following:

•

The transaction ID of a transaction in the TFILE

•

The transaction ID of a work request message in $RECEIVE

•

A nil value, indicating that there currently is no transaction in progress

The program module uses RESUMETRANSACTION (0) calls to set the current

transaction to the nil state, RESUMETRANSACTION (tag) calls to set the current

transaction to the transaction ID of a transaction in the TFILE, and

ACTIVATERECEIVETRANSID (tag) calls to set the current transaction to the

transaction ID of a work request message in $RECEIVE.

The program module must keep track of all the various tag values and use the proper

procedure call (ACTIVATERECEIVETRANSID or RESUMETRANSACTION) for each

individual tag value.

Note that a single program module could even act as both the requester and a server

for the same transaction. Suppose that process A begins a transaction and does a

WRITEREAD to process B. If process B then does a WRITEREAD back to process A,

that very same transaction (which is already in process A’s TFILE) could arrive in

process A’s $RECEIVE pseudofile as well. If that were to happen, the server

component of process A must reply to process B (and process B must then reply to

process A) before the requester component of process A can commit the transaction.