next up previous
Next: Transactions on Objects Up: No Title Previous: Variable Granularity Locking

Nested Transactions

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 consumers
The 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.



next up previous
Next: Transactions on Objects Up: No Title Previous: Variable Granularity Locking



Prasun Dewan
Thu Mar 10 10:57:47 EST 2005