A Notation for Transaction Models

1. A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter

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

3. A Graphical Metaphor for Rules

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

5. The Rule Language • For each atomic action define a set of rules that define its effect. • One 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) Indicates signal that cause rule to fire. How rule set is changed by firing. Signal sent as result of firing.

6. Rules For Flat Transactions • SB(T) : -> +(SA(system)|SA(T)),, BEGIN_WORK • Rule is fired when signal ‘Begin Work’ is received. • Adds 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 • Disables rule SB(T) and SC(T). • SC(T) : -> (delete(SB(T)), delete(SA(T))),, COMMIT_WORK • Disables rule SB(T) and SA(T).

7. Flat Transactions With Savepoints

8. Flat Transactions with Savepoints • Allow for partial rollback • In travel agent problem had to rollback entire transaction if one lag could not be reserved. • 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.

9. A B C A B C A B C system system system A C A C A C trigger trigger trigger A B C A B C A B C S1 S1 S1 A C A C A C trigger trigger a) Transaction has started, trigger trigger establishing savepoint 1 A B C A B C S2 S2 A C A C trigger b) Next savepoint trigger S2 has been taken A B C S3 A C c) Next savepoint S3 has been taken Flat Transactions With Savepoints

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

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

12. A B C A B C A B C system C1 C2 A C A C A C trigger 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 A B C A B C A B C system C1 C2 C3 A C A C A C A C trigger trigger 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". Chained Transactions

13. Restart Processing

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

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

16. Nested Transactions • Definition summarized from [Moss81] • A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. • 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. • The transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. • A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. • The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back.

17. Nested Transactions • Commit rule • The commit of a sub-transaction makes its results accessible to the parent transaction only. • 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. • Rollback rule • 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.

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

19. Nested Transactions

20. Nested Transactions Means that effect is conditioned on commit of parent

21. Nested Transactions vs. Savepoints

22. Distributed Transactions

23. Multi-Level Transactions

24. Using Multi-Level Transactions

25. Using Multi-Level Transactions II

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

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