TS/MP 2.5 Pathsend and Server Programming Manual

out. To ensure transaction backout, the server must call the ABORTTRANSACTION procedure after
reading the server request and before sending a reply. A call to ABORTTRANSACTION by the
server does not end the transaction—only the requestor can end it—but such a call imposes the
requirement that the requestor also call ABORTTRANSACTION, rather than ENDTRANSACTION,
after the reply of the requestor.
Writing a Server to Use the TMF Subsystem
If your application does not follow the structure described in “Recommended Structure for
Applications” (page 64), described previously, then you must consult the following checklist.
To writing a Pathway server to use the TMF subsystem:
1. Decide which files in the database must be audited.
2. Determine any modifications that are necessary to convert the application to follow the TMF
subsystem locking rules.
3. Decide how to group sequences of the application operations into TMF transactions (units of
recovery).
4. Ensure that any fault-tolerant servers respond correctly to file-system error 75: REQUESTING
PROCESS HAS NO CURRENT-TRANSACTION IDENTIFIER. A backup server that takes over
in mid-transaction does not have a current transaction identifier to send to the disk process;
therefore, the disk process returns error 75 to the server, which passes the error to the requestor.
If the requestor aborts and retries the transaction, the new request has a current transaction
identifier. HP recommends to change the servers, so they are not fault-tolerant servers.
5. Determine whether any new transaction deadlock situations are introduced as a result of TMF
implicit record locking and modify the application to avoid the deadlock. (Transaction deadlock
occurs when two transactions cannot proceed, because they are waiting for the other to release
a lock.) One way resolve with deadlock is to use timeout.
In addition, your requestor program must use the necessary transaction-control procedure calls or
statements to begin and end the transaction and to abort or restart the transaction, if necessary.
NOTE: Whenever your server begins work on a new queued message, it must call the
ACTIVATERECEIVETRANSID procedure to change the current transaction identifier, as described
in the HP NonStop Transaction Management Facility (TMF) Application Programmer’s Guide.
Using Audited and Nonaudited Files
TMF recovery strategy involves backing out the aborted transaction changes; backing out those
changes enables the transaction to be re-executed from the beginning (with a new transaction
identifier). This strategy means that if you decide to have a mixture of audited and nonaudited files
in the database, you must be careful: only changes to audited files are backed out. If a transaction
works on a mix of audited and nonaudited files, the operations on the nonaudited files must be
retryable.
A retryable operation is an operation that can be interrupted and repeated an indefinite number
of times without affecting the consistency of the database; for example, all reading operations are
retryable. Whether or not a writing operation (on a non audited file) is retryable depends on your
criteria for consistency of the data in the database. If the transaction changes both audited and
non audited files, you must analyze the transaction to determine whether backing it out and re
executing it affects consistency.
For example, consider a transaction that extracts records from a database, computes some
aggregates like averages or means, and then uses the aggregates to extract a subset of the extracted
records from the database for summary reporting. This transaction can be implemented by doing
the extraction twice, the first time to compute the aggregates and the second time to extract the
subset. You can place the extracted records in a nonaudited scratch file (each server can have its
own scratch file, to avoid conflict among them). If the transaction is aborted and restarted, the
Considerations for Servers That Use the TMF Subsystem 65