Transaction Management
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.
Finally, when several transactions update the database concurrently, the consistency
of data may no longer be preserved, even though each individual transaction
is correct. It is the responsibility of the concurrency-control manager to control
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 concept of a transaction has been applied broadly in database systems
and applications. While the initial use of transactions was in financial applications,
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.
Frequently Asked Questions
Recommended Posts:
- Characteristics of the Database Approach
- View of Data
- Subclasses, Superclasses, and Inheritance
- what is database management system
- Database-System Applications
- Specialization and Generalization
- Constraints and Characteristics of Specialization and Generalization Hierarchies
- Modeling of UNION Types Using Categories
- A Sample UNIVERSITY EER Schema, Design Choices, and Formal Definitions
- Example of Other Notation: Representing Specialization and Generalization in UML Class Diagrams
- Data Abstraction, Knowledge Representation, and Ontology Concepts
- Using High-Level Conceptual Data Models for Database Design
- Using High-Level Conceptual Data Models for Database Design
- Using High-Level Conceptual Data Models for Database Design
- Using High-Level Conceptual Data Models for Database Design