TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

TMF transactions act as brackets; that is, the statements are placed before and after the add record,
update record, and delete record procedures in your requester program.
Figure 6 (page 33) illustrates the use of the TMF subsystem by a Pathsend requester program and
a Pathway server program. In the illustration, the variable called TRANSID acts as a transaction
identifier.
Figure 6 Pathway Application Programming for the TMF Subsystem
Database Consistency and Concurrency
Potentially, all operations that alter the database are candidates for TMF protection. But before
you can apply TMF protection to your transactions, you need to determine:
• When to begin a TMF transaction
• Whether all the database update operations have to happen together in the same TMF
transaction or whether they can be parts of different transactions
To answer these issues, you have to establish your criteria for database consistency and decide
how much processing concurrency you can achieve in the application. For example, the Enter
Sales transaction affects several pieces of information: order data, inventory data, shipping data,
customer credit, and receivables. Upon examination of this transaction, you will see that it is
possible to make one general assertion about order processing and about the Enter Sales transaction
in particular: An order is not complete until every piece of information associated with the order
is recorded in the \REG, \CORP, and \WHS databases.
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
Designing Transactions 33