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

TMF Programming Environment

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

1-2

The TMF Transaction

Within the TMF programming environment, program operations that modify the content

of a protected database must be grouped together into TMF transactions.

From a syntactical perspective, a TMF transaction is an executed sequence of code

delimited by two unique programming statements: one indicating the start of the

transaction and the other indicating the end of the transaction.

From a program design perspective, however, the decision as to what best constitutes

a TMF transaction requires careful judgement; unfortunately, there is no simple

formula.

Defining a Transaction

The following characteristics might be helpful in defining transactions.

Shared Destiny

All of the database operations within a particular transaction have a shared destiny:

they are either all performed and their results committed (made permanent) or all

aborted and their results backed out.

Independent of Other Database Operations

In general, database operations that are not dependent upon one another should not

be bound together into a transaction. If the results of one operation leave the database

in a consistent state regardless of the results of another operation, the two operations

probably should not be bound together within a single TMF transaction.

Single Business Operation

Each TMF transaction often reflects a single business operation. For example,

consider the situation in which a customer is performing a sequence of operations at

an automated teller machine (ATM). The overall session at the ATM might include the

following operations:

•

A transfer of funds from the customer’s checking account to a savings account

•

A transfer of funds from the checking account to a charge card account

•

A cash withdrawal from the checking account

The session divides most effectively into three TMF transactions: one for the checking-

to-savings transfer, one for the checking-to-charge transfer, and one for the cash

withdrawal.

The primary reason for dividing the session into three transactions instead of making it

a single TMF transaction is that each operation independently transforms the database

from one consistent state to another consistent state. There is no logical reason why a