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

Designing Multithreaded Processes

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

3-13

Manipulating the Current Transaction

Immediately after accepting an incoming work request from $RECEIVE, the server

must call the LASTRECEIVE procedure to obtain the tag value associated with that

work request.

After each READUPDATE completion, the transaction identifier associated with the

particular incoming work request becomes the server’s current transaction.

Thereafter, you use the tag value (obtained by using LASTRECEIVE) in

ACTIVATERECEIVETRANSID procedure calls to change the server’s current

transaction from one transaction to another.

When you are done processing $RECEIVE requests and wish to return control to a

transaction that you previously initiated, you merely supply the tag value from the

associated BEGINTRANSACTION call in a RESUMETRANSACTION procedure call.

As with single-threaded servers, a successful call to ABORTTRANSACTION

automatically resets the current transaction to the nil state. Because a multithreaded

server is continually switching its attention from one transaction to another, each

portion of code that resumes the processing of a transaction must explicitly set the

current transaction to the proper value by using an ACTIVATERECEIVETRANSID call.

If the call to ABORTTRANSACTION fails, the current transaction identifier remains

unchanged and is the same identifier that was supplied to the ABORTTRANSACTION

procedure.

Replying to Requesters

Whenever you have opened $RECEIVE with a receivedepth greater than 1, the

REPLY procedure ignores the value of the server’s current transaction and requires

that you supply an explicit tag value in the procedure call.

NonStop Servers

In the TMF environment, there is no need for NonStop servers.

If a server process fails while working on one or more transactions, TMF automatically

aborts the affected transactions. When the associated requesters receive indication

that their 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.