nested transactions from OMG Transaction Service Specification (September 2003 Version 1.4)

1.2.4.1 Transaction Models

1.2.4.1 Transaction Models

The Transaction Service supports two distributed transaction models: flat transactions
and nested transactions. An implementation of the Transaction Service is not required
to support nested transactions.

Flat Transactions
The Transaction Service defines support for a flat transaction model. The definition of
the function provided, and the commitment protocols used, is modeled on the X/Open
DTP transaction model definition.1
A flat transaction is considered to be a top-level transaction that cannot have a child
transaction.

Nested Transactions
The Transaction Service also defines a nested transaction model. Nested transactions
provide for a finer granularity of recovery than flat transactions. The effect of failures
that require rollback can be limited so that unaffected parts of the transaction need not
rollback.

Nested transactions allow an application to create a transaction that is embedded in an
existing transaction. The existing transaction is called the parent of the subtransaction;
the subtransaction is called a child of the parent transaction.
Multiple subtransactions can be embedded in the same parent transaction. The children
of one parent are called siblings.

Subtransactions can be embedded in other subtransactions to any level of nesting. The
ancestors of a transaction are the parent of the subtransaction and (recursively) the
parents of its ancestors. The descendants of a transaction are the children of the
transaction and (recursively) the children of its descendants.

A top-level transaction is one with no parent. A top-level transaction and all of its
descendants are called a transaction family.

A subtransaction is similar to a top-level transaction in that the changes made on
behalf of a subtransaction are either committed in their entirety or rolled back.
However, when a subtransaction is committed, the changes remain contingent upon
commitment of all of the transaction’s ancestors.

Subtransactions are strictly nested. A transaction cannot commit unless all of its
children have completed. When a transaction is rolled back, all of its children are
rolled back.

Objects that participate in transactions must support isolation of transactions. The
concept of isolation applies to subtransactions as well as to top level transactions.
When a transaction has multiple children, the children appear to other transactions to
execute serially, even if they are performed concurrently.

Subtransactions can be used to isolate failures. If an operation performed within a
subtransaction fails, only the subtransaction is rolled back. The parent transaction has
the opportunity to correct or compensate for the problem and complete its operation.
Subtransactions can also be used to perform suboperations of a transaction in parallel,
without the risk of inconsistent results.

1. See Distributed Transaction Processing: The XA Specification, X/Open Document C193.
X/Open Company Ltd., Reading, U.K., ISBN 1-85912-057-1.