A Notation for Transaction Models Adapted from slides

A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter ECE 569 Lecture 07 -2. 1 1

Dependencies Between Transactions q Structural dependencies l Reflect the hierarchical organization of the system into abstract data types of increasing complexity. l reflects the invocation hierarchy of the system. q Dynamic dependencies l Arises from the use of shared data. l Can envelop any number of otherwise unrelated atomic actions. ECE 569 Lecture 07 -2. 2 2

A Graphical Metaphor for Rules ECE 569 Lecture 07 -2. 3 3

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

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

Rules For Flat Transactions q SB(T) : -> +(SA(system)|SA(T)), , BEGIN_WORK l Rule is fired when signal ‘Begin Work’ is received. l Adds rule that causes ‘Abort Work’ signal to be sent when SA(system) rule is fired. q SA(T) : ->(delete(SB(T)), delete(SC(T))), , ROLLBACK_WORK l Disables rule SB(T) and SC(T). q SC(T) : -> (delete(SB(T)), delete(SA(T))), , COMMIT_WORK l Disables rule SB(T) and SA(T). ECE 569 Lecture 07 -2. 6 6

Flat Transactions With Savepoints ECE 569 Lecture 07 -2. 7 7

Flat Transactions with Savepoints q Allow for partial rollback l In travel agent problem had to rollback entire transaction if one lag could not be reserved. l Instead 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. ECE 569 Lecture 07 -2. 8 8

Flat Transactions With Savepoints A B C system A C A B C system A A B C system C A C trigger A B C S 1 A C a) Transaction has started, establishing savepoint 1 ECE 569 Lecture 07 -2. 9 trigger A B C S 2 A C b) Next savepoint S 2 has been taken trigger A B C S 3 A C c) Next savepoint S 3 has been taken 9

Flat Transactions With Savepoints q The rule system for transactions with savepoints SB(Sn) SA(R) SC(Sn) SS(Sn) : : (R<Sn) : : ECE 569 Lecture 07 -2. 10 -> -> , , BEGIN WORK , SA(Sn-1), ROLLBACK WORK , SC(Sn-1), COMMIT WORK +(SA(Sn)|SA(Sn + 1)), SB(Sn + 1), 10

Chained Transaction q Sequence of transactions l Upon commitment of one transaction, next one begins l Not possible to rollback beyond current transaction l When one transaction ends all resources not needed in future are freed, e. g. , - give up unnecessary locks - close unneeded cursors ECE 569 Lecture 07 -2. 11 11

Chained Transactions A B C system A C A B C A C 1 A B C C 2 C trigger A C 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. A B C system A C trigger A B C A C 1 A B C A C 2 C A B C C 3 C A C trigger b) The first transaction in the chain has committed; the second one got started as part of commit of C 1. Now the second one is structurally dependent on "system". ECE 569 Lecture 07 -2. 12 12

Restart Processing ECE 569 Lecture 07 -2. 13 13

Chained Transactions vs. Savepoints q Workflow structure l Both allow a substructure to be imposed on a long-running application program. q Commit versus savepoint l Chaining step irrevocably completes a transaction l Rollback is limited to the currently active transaction. q Lock handling l COMMIT allows the application to free locks that it does not later need. ECE 569 Lecture 07 -2. 14 14

Chained Transactions vs. Savepoints q Work lost l Savepoints allow more flexible state restoration. l Savepoints are not persistent - enclosing transaction is aborted. - After failure entire transaction must be redone. l With chained transactions, the state of the most recent commit is restored. - Less work is lost in that situation. ECE 569 Lecture 07 -2. 15 15

Nested Transactions q Definition summarized from [Moss 81] l A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. l Transactions at the leaf level are flat transactions. The distance from the root to the leaves can be different for different parts of the tree. l The transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. l A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. l The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back. ECE 569 Lecture 07 -2. 16 16

Nested Transactions q Commit rule l The commit of a sub-transaction makes its results accessible to the parent transaction only. l The 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. q Rollback rule l If 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. ECE 569 Lecture 07 -2. 17 17

Nested Transactions q Visibility rule l All changes done by a sub-transaction become visible to the parent transaction upon the sub-transaction’s commit. l All objects held by a parent transaction can be made accessible to its sub-transactions. l Changes made by a sub-transaction are not visible to its siblings. ECE 569 Lecture 07 -2. 18 18

Nested Transactions ECE 569 Lecture 07 -2. 19 19

Nested Transactions Means that effect is conditioned on commit of parent ECE 569 Lecture 07 -2. 20 20

Nested Transactions vs. Savepoints 21

Distributed Transactions 22

Multi-Level Transactions 23

Using Multi-Level Transactions 24

Using Multi-Level Transactions II 25

Using Multi-Level Transactions q. Abstraction hierarchy l The entire system consists of a strict hierarchy of objects with their associated operations. q. Layered abstraction l The objects of layer n are completely implemented by using operations of layer n-1. q. Discipline l There are no shortcuts that allow layer n to access objects on a layer other than n-1. 26

Multi-Level Transactions q Advantages l Subtransaction can commit immediately - Objects become available to other transactions sooner - Better peformance q Disadvantages l Requires a well-structured and well-understood structure l Requires the definition of a compensating transaction for each subtransaction that commits early l Recovery by compensating transactions often takes longer than physical recovery (copying back the before image). ECE 569 Lecture 07 -2. 27 27