Imagine a software engineering project trying to fix a bug. One might want software engineers to make fixs two bugs in parallel but not create a new release until both bugs have been fixed and a check has been made that the two bug fixes do not interfere with each other. Regular transactions cannot support this scenario as units of parallel execution are also units of consistency. However, in our example, fix to an individual bug does not necessarily leave the project in a consistent state as this fix may not work with the fix to the other bug.
The problem we have is that so far, our units of concurrency (transactions) have been required to also be units of atomicity, consistency, isolation, and durability. These properties are not orthogonal and several concurrency schemes support concurrency units (also called transactions) with only some of these properties
Nested transactions is one such concurrency scheme. It supports top-level transactions with all of the ACID properties. In addition, to support concurrent execution of independent actions (such as modification to two different procedures of a program) within these transactions, it allows a top-level transaction to root a tree of nested transactions. The following is an example of a top-level transaction with nested subtransactions T11 and T12.
T1:FixBug T11: Fix Bug 1 T12: Fix Bug 2 Link Changed files with rest of the system Run Tests Fix Documentation Mail to consumersThe transaction also contains basic commands such as Link and Send Mail. These commands are executed serially with respect to each other, much as statements in compound statement are exeuted serially with respect to each other. Should they also be executed serially with respect to the nested subtransactions or do they form a separate thread? In the above example, should the Link command wait for the two subtransactions to complete or be executed in parallel with them. Each of the alternatives has advantages. Allowing them to execute in parallel allows more concurrency while executing them serially allows top-level commands to be synchronized with nested transactions, which is what we want in this example.
Like top-level transactions,
nested transactions have the following properties:
A transaction is serializable with respect to its siblings,
that is,
accesses to shared resources by sibling transactions have to obey the
read-write and write-write synchronization rules.
A transaction is a unit of recovery,
that is,
it can be aborted independently of its siblings (modula the problem of
cascaded aborts).
A transaction is a unit of atomicity,
that is,
either all or none of the effects of its actions occur.
In addition,
they have the following properties which stem from the
fact that unlike top-level transactions they have parents:
A nested transaction's actions are not considered to conflict
with its parent's actions.
Thus,
it can lock a resource locked by its parent
as long as none of its siblings have locked it (in an incompatible mode).
A nested transaction can lock a datum in some mode
only if its parent has locked the datum in the same or stronger mode.
A parent transaction's actions are considered to conflict
with its child's actions but not vice versa.
Thus,
it cannot access a resource if a child's lock prohibits the access.
Thus,
the child's lock wins.
(This is relevant only if the commands of the parent transaction
can execute in parallel with the commands of the child transaction.)
An abort by a child transaction does not automatically abort the parent
transaction.
The parent is free to try alternative nested transactions.
Thus, if a subtransaction accessing a particular server fails,
another subtransaction accessing another server can be tried by the parent
transaction.
A commit by a child transaction releases the locks held by it
to its parent and makes its actions be part of
the action set of its parent transaction.
Thus,
when the parent commits,
it commits not only those actions it performed directly
but also those performed by its descendents.
Notice, a nested transaction is not a unit of consistency or durability since it does not on its own leave the database in a consistent state.