NonStop Systems Introduction

NonStop Systems Introduction—527825-001
5-1
5 Transaction Management
So far we have seen the following major components of the NonStop application server
environment:
•
The application servers coordinate the execution of ZLE applications and provide
for communication between client programs and server programs.
•
The SQL/MX relational database management system retrieves and updates data
in relational database tables on behalf of applications and end users.
Another major component of the NonStop application server environment is TMF. The
role of TMF is to protect the database from the effects of transaction failures, system
failures, and media (disk drive) failures.
TMF provides the following facilities to maintain data integrity during transaction
processing:
•
Transaction backout cancels database updates made by an individual transaction
when the transaction fails before completion.
•
Volume recovery recovers database files to their most recent consistent state
when they become inconsistent because of a disk volume or system failure.
•
File recovery reconstructs specified audited files when the current copies on the
data volume are not usable.
Because TMF provides these backout and recovery features automatically, application
developers do not need to write special code to handle these situations.
What Is a TMF Transaction?
To understand the role of TMF in protecting databases during transaction processing,
look more closely at the concept of an online transaction.
An online transaction is a computer model of a business event. For example, if the
business event is a transfer of funds between a savings account and a checking
account, the transaction is the group of computer operations that carry out the transfer
of funds. These operations include collecting input from the user (names of accounts
and amount to be transferred), updating the user’s savings account and checking
account records, and sending a confirmation message to the user (a printed
transaction record with the new checking and savings balances).
Because the online transaction takes place in real time (at the same moment as the
business event that it models), it runs the risk of being interrupted before completion.
This is not so bad in itself, because a well-designed application can start the
transaction again after the cause of failure is corrected. The real problem is that when
a transaction failure takes place, the transaction might have completed some of its
changes to the database but not others. As a result, some records in the database
might be inconsistent with each other.