BASIC FUNCTIONING OF

PARENT & CHILD

TRANSACTIONS

 A nested transaction provides a transactional guarantee

for a subset of operations performed within the scope of a

larger transaction.
This allows us to commit and abort the subset of

operations independently of the larger transaction.

 Here the main program becomes the top level action.

Within it objects run as nested actions i.e. child

transactions.

Different Types
Closed Nesting
A transaction may have multiple concurrent children.
Using the log model, if a child commits, we append its log to its
parents log.
If a child aborts, we undo its actions and discard its log.
A child abort does not abort its parent, though the parent may be
notified of the abort and take alternative action of its choosing,
including aborting itself.
One interesting property of the closed nesting model is that a
childs operations are deemed never to conflict with operations of
its parent (or any ancestor).

 Linear Nesting
We restrict a transaction to have at most one child at a time.
The tree of running descendants of any transaction is a line, not a
general tree structure.
One can identify a transaction solely by a top-level transaction id
(the original ancestor of the transaction) plus a nesting level.
This greatly simplifies determining ancestor-descendant
relationships in hardware, and also permits some useful further
optimizations.

 Open Nesting
Operations are considered at a higher level of abstraction.
Open-nested transactions are allowed to commit to the shared
memory independently of their parent transactions, optimistically
assuming that the parent will commit.
Use compensating action to undo the childs forward action at a
higher-level of abstraction
E.g., malloc() compensated by free()

Rules:
When the child transaction is active, parent transaction

may not perform any operations other than to

commit/abort or creating more child transaction.
No effect on state of parent transaction when a nested

transaction is committed.
Parent can see the modifications.
These modifications are hidden until parent also commits.

 If parent abort or commit the child also performs the

same.
The locks are held by the parent transaction until it

commits.
The depth of the nested transaction is limited by memory.
A transaction is a unit of atomicity i.e. either all, or none of

the effects of its actions occur.

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

Example:
BEGIN TRAN Tran1
GO
BEGIN TRAN Nested Tran
GO
INSERT INTO Table1 DEFAULT Values
GO 10
COMMIT TRAN Nested Tran
SELECT * FROM Table1
We get back 10 results.

ROLLBACK TRAN Tran1

The 10 transactions are gone.
The nested transaction is based on the action of the outer

most transaction.
Since we rolled back the outer transaction, the entire
transaction is rolled back no matter what we did in
between.
If we had committed Tran1, then the nested transaction
would have also commited.

Why nested transactions?

Partial abortions: Nested transactions make it possible for

subtransactions to abort without aborting the whole

transaction.
1. Conditional synchronization: can be supported by
aborting the current transaction if a precondition is not met,
and only scheduling the transaction to be retried when the
pre-condition is met (for example, a dequeue operation
would wait until there is at least one element in the queue).
2. Fault management: a program may try to perform an
action, and in the case of failure, change to a different
strategy. In both these scenarios, performance can be
improved with nesting by aborting and retrying only the
inner-most sub-transaction.

 Example:
We may organize sending a mail to multiple recipients as a
top-level transaction T where sending a mail to an individual
recipient is done in subtransactions to T.
When all subtransactions to T have completed T may decide
if sending the mail should be aborted or tried committed. This
decision can depend on which subtransactions made a
provisionary commit (ie: who received the mail).

 Since the subtransactions to a given transaction are

executed in an order determined by the transaction system,

the transaction system has some flexibility in trying to obtain
concurrency.
Note that for this to give any advantage it is essential that the

client uses multiple threads to execute subtransactions

THANK YOU