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

Nested Transactions

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. [ Moss ] 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.

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.
An abort by a child transaction does not automatically abort the parent transaction. The parent is free to try alternative nested transactions.
A commit by a child transaction releases the locks held by it to its parent and makes its actions be part of 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
Wed Apr 7 11:52:42 EDT 1999