Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-4
Transaction Coordination
Transactions Are Isolated
To process the database correctly, the application must be able to assume that its input
from the database is consistent, regardless of any concurrent changes being made to
the database.
The following example shows the need to control concurrent access so that each
transaction effectively executes in isolation. The first part of Figure 4-1 on page 4-5
shows two transactions accessing the same record without concurrency control.
Transaction T1 tries to add $500 to the checking balance. Transaction T2 tries to add
$100 dollars. Because transaction T2 reads the balance before T1 updates it, it does
not see the changes made by T1. T2 then writes its new balance after T1, thus
overwriting the changes made by T1. The changes made by T1 are lost.
TMF provides concurrency control by managing locks on records or rows of data that
are accessed and updated in each transaction. Each transaction locks records (or
rows) as it accesses them and does not release the locks until the transaction
commits. In this way, other transactions cannot use the data until the database is in a
consistent state. In the example shown in the second part of Figure 4-1, the read
operation in transaction T2 cannot execute until transaction T1 commits.
Whether T1 or T2 is performed first makes no difference to the consistency of the
database after both transactions have committed. In the example shown in Figure 4-1,
the end result is the same whether T1 or T2 executes first. Other examples can have a
different result depending on which transaction executes first, but the database will
always be consistent. Consider, for example, what would happen if transaction T2 in
Figure 4-1 attempts to withdraw $100:
•
If T1 executes first and successfully adds $500 to the balance then the account
contains enough money for T2 to make the $200 withdrawal.
•
If T2 tries to execute first it will fail because the account does not contain enough
funds to cover the withdrawal.
The results are different but consistent in that no money is lost.
Transactions Are Durable
Once the transaction is committed, all changes made by the transaction must be
guaranteed to be permanent. In addition to writing the changes permanently to disk,
the HP system provides after-image logging, which provides an audit trail for keeping a
record of all past transactions. This record of past transactions can be used to correct
the database even in the unlikely event of a catastrophic failure.
Transaction Coordination
A transaction usually involves more than one process. Typically, a requester or client
process initiates the transaction and involves one or more server processes to provide
services such as manipulating the database or placing requests on a transaction-