Often, several operations on the database form a single logical unit of work. An
example is a funds transfer, as in Section 1.2, 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 A and 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 database- consistency constraints. That is, if the database was consistent when a transaction started, the database must be consistent when the transaction successfully ter- minates. 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 transac- tions, 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 other will 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 com- plete 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.
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 database- consistency constraints. That is, if the database was consistent when a transaction started, the database must be consistent when the transaction successfully ter- minates. 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 transac- tions, 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 other will 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 com- plete 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.
Finally, when several transactions update the database concurrently, the con-
sistency of data may no longer be preserved, even though each individual transac-
tion is correct. It is the responsibility of the concurrency-control manager to con-
trol the interaction among the concurrent transactions, to ensure the consistency
of the database. The transaction manager consists of the concurrency-control
manager and the recovery manager.
The basic concepts of transaction processing are covered in Chapter 14. The management of concurrent transactions is covered in Chapter 15. Chapter 16 covers failure recovery in detail.
The concept of a transaction has been applied broadly in database systems and applications. While the initial use of transactions was in financial applica- tions, the concept is now used in real-time applications in telecommunication, as well as in the management of long-duration activities such as product design or administrative workflows. These broader applications of the transaction concept are discussed in Chapter 26.
The basic concepts of transaction processing are covered in Chapter 14. The management of concurrent transactions is covered in Chapter 15. Chapter 16 covers failure recovery in detail.
The concept of a transaction has been applied broadly in database systems and applications. While the initial use of transactions was in financial applica- tions, the concept is now used in real-time applications in telecommunication, as well as in the management of long-duration activities such as product design or administrative workflows. These broader applications of the transaction concept are discussed in Chapter 26.
Post a Comment