ECE569 Lecture Spring 2004 A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter

ECE569 Lecture Spring 2004 Dependencies Between Transactions  Structural dependencies lReflect the hierarchical organization of the system into abstract data types of increasing complexity. lreflects the invocation hierarchy of the system.  Dynamic dependencies lArises from the use of shared data. lCan envelop any number of otherwise unrelated atomic actions.

ECE569 Lecture Spring 2004 A Graphical Metaphor for Rules

ECE569 Lecture Spring 2004 Describing Flat Transactions ABC AC system ABC AC T ABC AC ABC AC T ABC AC A B C AC T a) Transaction T is active; an abort of the system transaction will cause it to roll back, too. trigger b) Termination scenario 1: Transaction T has committed; all of its event ports are deactivated; the final state is highlighted. c) Termination scenario 2: Same as scenario 1, but T assumes the final abort state.

ECE569 Lecture Spring 2004 The Rule Language  For each atomic action define a set of rules that define its effect. lOne rule for each state transition the action can perform  The structure of an arbitrary rule is as follows: ( rule identifier):(preconditions) -> (rule modifier list), (signal list), (state transition ) How rule set is changed by firing. Signal sent as result of firing. Indicates signal that cause rule to fire.

ECE569 Lecture Spring 2004 Rules For Flat Transactions  SB(T) : -> +(SA(system)|SA(T)),, BEGIN_WORK lRule is fired when signal ‘Begin Work’ is received. lAdds rule that causes ‘Abort Work’ signal to be sent when SA(system) rule is fired.  SA(T) :->(delete(SB(T)),delete(SC(T))),, ROLLBACK_WORK lDisables rule SB(T) and SC(T).  SC(T) : -> (delete(SB(T)), delete(SA(T))),, COMMIT_WORK lDisables rule SB(T) and SA(T).

ECE569 Lecture Spring 2004 Flat Transactions With Savepoints

ECE569 Lecture Spring 2004 Flat Transactions with Savepoints  Allow for partial rollback lIn travel agent problem had to rollback entire transaction if one lag could not be reserved. lInstead do the following  Attempt to reserve San Francisco to Frankfurt if successful establish savepoint 2  Attempt to reserve Frankfurt to Milan - if successful establish savepoint 3.  If not rollback to savepoint 2 and try for Frankfurt to Rome - if successful establish savepoint 4.

ECE569 Lecture Spring 2004 Flat Transactions With Savepoints

ECE569 Lecture Spring 2004 Flat Transactions With Savepoints  The rule system for transactions with savepoints SB(Sn) : ->,,BEGIN WORK SA(R) : (R,SA(Sn-1), ROLLBACK WORK SC(Sn) : ->,SC(Sn-1), COMMIT WORK SS(Sn) : -> +(SA(Sn)|SA(Sn + 1)), SB(Sn + 1),

ECE569 Lecture Spring 2004 Chained Transaction  Sequence of transactions lUpon commitment of one transaction, next one begins lNot possible to rollback beyond current transaction lWhen one transaction ends all resources not needed in future are freed, e.g.,  give up unnecessary locks  close unneeded cursors

ECE569 Lecture Spring 2004 Chained Transactions ABC AC ABC AC system C1 trigger ABC AC C2 trigger a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one. ABC AC ABC AC system C1 trigger ABC AC C2 trigger ABC AC C3 b) The first transaction in the chain has committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on "system".

ECE569 Lecture Spring 2004 Restart Processing

ECE569 Lecture Spring 2004 Chained Transactions vs. Savepoints  Workflow structure lBoth allow a substructure to be imposed on a long-running application program.  Commit versus savepoint lChaining step irrevocably completes a transaction lRollback is limited to the currently active transaction.  Lock handling lCOMMIT allows the application to free locks that it does not later need.

ECE569 Lecture Spring 2004 Chained Transactions vs. Savepoints  Work lost lSavepoints allow more flexible state restoration. lSavepoints are not persistent - enclosing transaction is aborted.  After failure entire transaction must be redone. lWith chained transactions, the state of the most recent commit is restored.  Less work is lost in that situation.

ECE569 Lecture Spring 2004 Nested Transactions  Definition summarized from [Moss81] lA nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. lTransactions at the leaf level are flat transactions. The distance from the root to the leaves can be different for different parts of the tree. lThe transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. lA sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. lThe rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back.

ECE569 Lecture Spring 2004 Nested Transactions  Commit rule lThe commit of a sub-transaction makes its results accessible to the parent transaction only. lThe sub-transaction will finally commit (i.e. release its results to the outside world) if and only if it has committed itself locally and all its ancestors up to the root have finally committed.  Rollback rule lIf a (sub-) transaction at any level of nesting is rolled back, all its sub-transactions are also rolled back, independent of their local commit status. This is applied recursively down the nesting hierarchy.

ECE569 Lecture Spring 2004 Nested Transactions  Visibility rule lAll changes done by a sub-transaction become visible to the parent transaction upon the sub-transaction’s commit. lAll objects held by a parent transaction can be made accessible to its sub-transactions. lChanges made by a sub-transaction are not visible to its siblings.

ECE569 Lecture Spring 2004 Nested Transactions

ECE569 Lecture Spring 2004 Nested Transactions Means that effect is conditioned on commit of parent

ECE569 Lecture Spring 2004 Nested Transactions vs. Savepoints

ECE569 Lecture Spring 2004 Distributed Transactions

ECE569 Lecture Spring 2004 Multi-Level Transactions

ECE569 Lecture Spring 2004 Using Multi-Level Transactions

ECE569 Lecture Spring 2004 Using Multi-Level Transactions II

ECE569 Lecture Spring 2004 Using Multi-Level Transactions  Abstraction hierarchy lThe entire system consists of a strict hierarchy of objects with their associated operations.  Layered abstraction lThe objects of layer n are completely implemented by using operations of layer n-1.  Discipline lThere are no shortcuts that allow layer n to access objects on a layer other than n-1.

ECE569 Lecture Spring 2004 Multi-Level Transactions  Advantages lSubtransaction can commit immediately  Objects become available to other transactions sooner  Better peformance  Disadvantages lRequires a well-structured and well-understood structure lRequires the definition of a compensating transaction for each subtransaction that commits early lRecovery by compensating transactions often takes longer than physical recovery (copying back the before image).