Often, several operations on the database form a single logical unit of work. An
example is a funds transfer, in which one department account
(say A) is debited and another department account (say B) is credited. Clearly, it
is essential that either both the credit and debit occur, or that neither occur. That
is, the funds transfer must happen in its entirety or not at all. This all-or-none
requirement is called atomicity. In addition, it is essential that the execution of the
funds transfer preserve the consistency of the database. That is, the value of the
sum of the balances of Aand B must be preserved. This correctness requirement
is called consistency. Finally, after the successful execution of a funds transfer,
the new values of the balances of accounts A and B must persist, despite the
possibility of system failure. This persistence requirement is called durability.
A transaction is a collection of operations that performs a single logical
function in a database application. Each transaction is a unit of both atomicity
and consistency. Thus, we require that transactions do not violate any databaseconsistency
constraints. That is, if the database was consistent when a transaction
started, the database must be consistent when the transaction successfully terminates.
However, during the execution of a transaction, it may be necessary
temporarily to allow inconsistency, since either the debit of A or the credit of B
must be done before the other. This temporary inconsistency, although necessary,
may lead to difficulty if a failure occurs.
It is the programmer’s responsibility to define properly the various transactions,
so that each preserves the consistency of the database. For example, the
transaction to transfer funds from the account of department A to the account of
department B could be defined to be composed of two separate programs: one
that debits account A, and another that credits account B. The execution of these
two programs one after the otherwill indeed preserve consistency.However, each
program by itself does not transform the database from a consistent state to a new
consistent state. Thus, those programs are not transactions.
Ensuring the atomicity and durability properties is the responsibility of the
database system itself—specifically, of the recovery manager. In the absence of
failures, all transactions complete successfully, and atomicity is achieved easily.
However, because of various types of failure, a transaction may not always complete
its execution successfully. If we are to ensure the atomicity property, a failed
transaction must have no effect on the state of the database. Thus, the database
must be restored to the state in which it was before the transaction in question
started executing. The database system must therefore perform failure recovery,
that is, detect system failures and restore the database to the state that existed
prior to the occurrence of the failure.