TMF Introduction (G06.26+)

TMF Application Programming
HP NonStop TMF Introduction—522414-002
5-12
Developing Servers for Database Access
If a transaction is aborted for any reason, all of its changes to audited database files
are backed out by TMF. In most cases, the requester program restarts the transaction
at the BEGIN-TRANSACTION statement. The new transaction is assigned a new
transaction identifier by the TCP.
ABORT-TRANSACTION stops the processing of a transaction. TMF backs out all
database changes made by the transaction and does not restart the transaction.
END-TRANSACTION identifies the end of a transaction and indicates that the
transaction’s database changes should be committed. After END-TRANSACTION is
completed, the transaction cannot undo any of its changes and the terminal is switched
out of transaction mode.
RESTART-TRANSACTION causes TMF to back out a transaction and restart it at the
BEGIN-TRANSACTION statement with a new transaction identifier. The new
transaction identifier is passed to the servers for subsequent database access.
Developing Servers for Database Access
Applications using a mixed SQL and Enscribe database also have TMF protection for
transaction and database recovery.
Mixed database access can be either through a single server or multiple servers. TMF
monitors all database access on a transaction basis by associating all access with the
transaction identifier passed from the requester to the server.
An HP COBOL server accessing a mixed database is shown in Figure 5-4. HP
COBOL allows embedding SQL statements in the program. The program accesses
the SQL database by using the SQL statements. The program accesses the Enscribe
database by using HP COBOL statements.
Transaction Design
Transaction design involves asking the following primary questions:
•
What is the work to be accomplished within the application (for example, order
entry or account balancing)?
•
How can the work be divided into a number of transactions that can be recovered,
if necessary, by TMF?
Factors that influence the answers to these questions are:
•
Concurrency—How long should locks on the data be held for a transaction?
•
Performance—How much extra disk input/output, server activity, and TCP memory
requirements are involved in the choice of one design over another?
•
Consistency—How large is the unit of recovery for each transaction, and is it
adequate for the application?