Imagine a software engineering project trying to fix a bug. One might want software engineers to edit two buggy files in parallel but not commit either of them until they have been both linked with the rest of the system. Regular transactions cannot support this scenario as units of parallel execution are also units of consistency. However, in our example, change to each individual file does not necessarily leave the project in a consistent state as the file may not work with other files.
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 and Compile F1 T12: Fix and Compile F2 Link F1 and F2 with F3 ... FN Send Mail to CustomersThe 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 other the above example, should the Link command wait for the two subtransactions to complete or be executed in parallel with each other. Each of the alternatives has advantages. Allowing them to execute in parallel allows more concurrency while execute 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 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.