Nested transaction
Encyclopedia
With reference to a database transaction
, a nested transaction occurs when a new transaction is started by an instruction that is already inside an existing transaction. The new transaction is said to be nested within the existing transaction, hence the term.
Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. This means that a commit in an inner transaction does not necessary persist updates to the database.
In some databases, changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed. According to some, this follows from the isolation property of transactions.
The capability to handle nested transactions properly is a prerequisite for true component based application architectures. In a component-based encapsulated architecture, nested transactions can occur without the programmer knowing it. A component function may or may not contain a database transaction (this is the encapsulated secret of the component. See Information hiding
). If a call to such a component function is made inside a BEGIN - COMMIT bracket, nested transactions occur. Since popular databases like MySQL
do not allow nesting BEGIN - COMMIT brackets, a framework or a transaction monitor is needed to handle this. When we speak about nested transactions, it should be made clear that this feature is DBMS dependent and is not available for all databases.
Theory for nested transactions is similar to the theory for flat transactions, and was introduced in the following paper:
The banking industry usually processes financial transactions using Open Nested Transactions, which is a looser variant of the nested transaction model that provides higher performance while accepting the accompanying trade-offs of inconsistency. Open Nested Transactions are discussed in the following paper:
Database transaction
A transaction comprises a unit of work performed within a database management system against a database, and treated in a coherent and reliable way independent of other transactions...
, a nested transaction occurs when a new transaction is started by an instruction that is already inside an existing transaction. The new transaction is said to be nested within the existing transaction, hence the term.
Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. This means that a commit in an inner transaction does not necessary persist updates to the database.
In some databases, changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed. According to some, this follows from the isolation property of transactions.
The capability to handle nested transactions properly is a prerequisite for true component based application architectures. In a component-based encapsulated architecture, nested transactions can occur without the programmer knowing it. A component function may or may not contain a database transaction (this is the encapsulated secret of the component. See Information hiding
Information hiding
In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed...
). If a call to such a component function is made inside a BEGIN - COMMIT bracket, nested transactions occur. Since popular databases like MySQL
MySQL
MySQL officially, but also commonly "My Sequel") is a relational database management system that runs as a server providing multi-user access to a number of databases. It is named after developer Michael Widenius' daughter, My...
do not allow nesting BEGIN - COMMIT brackets, a framework or a transaction monitor is needed to handle this. When we speak about nested transactions, it should be made clear that this feature is DBMS dependent and is not available for all databases.
Theory for nested transactions is similar to the theory for flat transactions, and was introduced in the following paper:
The banking industry usually processes financial transactions using Open Nested Transactions, which is a looser variant of the nested transaction model that provides higher performance while accepting the accompanying trade-offs of inconsistency. Open Nested Transactions are discussed in the following paper:
Further reading
- Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery, Morgan Kaufmann, 2002, ISBN 1558605088