TS/MP Pathsend and Server Programming Manual (G06.24+, H06.03+)

Designing Your Application
NonStop TS/MP Pathsend and Server Programming Manual–132500
2-8
Protecting Transactions
To illustrate this assertion, consider a situation where a transaction fails after it changes
the customer’s balance, records the order information, and records the order invoice, but
before it records the shipping information. In this scenario, the customer is going to be
billed for an order never received. Consequently, your basic criterion for database
consistency is as follows: all database updates that are related to the order must be part
of one TMF transaction.
Any record modified or inserted by a database operation that is protected by the TMF
subsystem is locked and unavailable to other transactions until the initial transaction
ends successfully. This type of locking protocol means that you always have a design
tradeoff—consistency versus concurrency—with respect to locking records that are
actively accessed by the application. If records are locked too early, other transactions
cannot access them and the application’s concurrency (its ability to process many
transactions at the same time) suffers.
As the Enter Sales transaction demonstrates, all of the data collection and validation
operations can happen before you begin the TMF transaction—although some
revalidation may be done again as part of the transaction. Assembling the order header
and assembling the order involve reading records in the database but not changing the
records. The rest of the operations change the database and should all be done within a
TMF transaction.
As a general rule, you should design the application’s transactions to maintain
consistency under all circumstances. After the application is installed and running
successfully, you can look for ways to improve its concurrency.
Aborting Transactions
If the requester or the server program detects a problem during the processing of a TMF
transaction, the requester or server causes the transaction to be aborted with a special
procedure call or statement (for example, a call to ABORTTRANSACTION in a
Pathsend program). For requesters, the statement that aborts a transaction is executed in
lieu of the statement that ends a transaction; for example, in a Pathsend program the
requester either completes the transaction with a call to ENDTRANSACTION or causes
it to be backed out, because of an error, with a call to ABORTTRANSACTION.
In the past, program designs typically assigned the task of aborting transactions to
requesters. Current program design often assigns that task to servers. Servers abort
transactions and inform the requesters of those actions, thus ensuring protection of data.
The aborting of transactions by servers is described further under Designing Server
Programs, later in this section.
The TMF subsystem backs out aborted transactions by using information contained in
the TMF audit-trail files. For more information about transaction backout and audit-trail
files, refer to the NonStop TM/MP Application Programmer’s Guide.