TMF Application Programmer's Guide (G06.26+)
Designing Single-Threaded Processes
HP NonStop TMF Application Programmer’s Guide—522419-005
2-4
Terminating Transactions
After being called, ABORTTRANSACTION returns control immediately to the
requester. Because the disk process holds locks on the affected database records until
after the relevant changes have been backed out, the requester can safely initiate a
new transaction involving the same database files without fear of encountering
inconsistent data. If the new transaction requires access to a database record whose
content was altered by the aborted transaction, the record lock prevents access to that
record until the changes have been successfully backed out.
Because ABORTTRANSACTION is a function-type procedure, it returns a file system
error code in the status variable. The code 0 indicates successful completion (the
call has initiated transaction abort); 76 indicates that the transaction was already in the
process of ending; 75 indicate that the transaction could not be aborted. For a
complete list of the file system error codes that apply to ABORTTRANSACTION calls,
see Parameters under the description of ABORTTRANSACTION in Section 4.
Unilateral Aborts
Once a transaction is initiated, either of the following conditions can occur:
1. One of the servers doing work on behalf of the transaction issues an
ABORTTRANSACTION call.
2. TMF or the file system aborts the transaction.
These types of transaction aborts are referred to as unilateral aborts because the
requester that initiated the transaction has no recourse—the transaction is
unconditionally aborted.
Any of the following situations will cause a unilateral abort:
•
A requester or its processor module fails.
•
A server or its processor module fails.
•
A disk process or its processor module fails.
•
A transaction remains on the system longer than TMF can tolerate.
•
A waited WRITEREAD to a server process times out before the server can reply.
•
An AWAITIO call times out before a server can reply.
•
A requester cancels a WRITEREAD to a server process.
•
A requester closes a server process that has not yet replied to a WRITEREAD.
•
A requester closes its TFILE while a transaction is still in progress.
•
A server issues an ABORTTRANSACTION call.
•
A server closes $RECEIVE before having replied to a work request message.
•
An operator manually aborts the transaction.