Ch 4 TransactionOriented Computing Dr Kien A Hua

Ch 4. Transaction-Oriented Computing Dr. Kien A. Hua

The Temporary Update Problem: T 2 reads the invalid “temporary” value. 2

The Lost Update Problem This update is lost! 3

The Incorrect Summary Problem 210 75 + 80 + 60 Inconsistent! 4

Outline • • Atomic Action and Flat Transactions. Sphere of Control. Notations Transaction Models 5

ACID Properties A transaction can be considered a collection of actions with the following properties: • Atomicity: A transaction’s changes to the state are atomic – either all happen or none happen. • Consistency: A transaction is a correct transformation of the state. • Isolation: Even though transactions execute concurrently, it appears to each transaction, T, that other executed either before or after T, but not both. • Durability: Once a transaction completes successfully, its changes to the state survive failures. 6

Disk Writes as Atomic Actions (1) Atomicity of a disk write operation would mean that either the entire block is correctly transferred to the specified slot, or the slot remains unchanged. 1. Single disk write: Problem: If there is a power loss in the middle of the operation, it might happen that the first part of the block is written, but the rest is not. 2. Read-after-Write: First issues a single disk write, then reads the block from disk and compares the result with the original block. Problem: There is no provisions to return to the initial state. 7

Disk Writes as Atomic Actions (2) 3. Duplexed write: Each block is written to two places on disk 4. Logged write: The old contents of the block are first read and then written to a different place. Then the block is modified, and eventually written to the old location Observation: Even simple operations cannot simply be declared atomic; rather, atomicity is a property for which the operations have to be designed and implemented. 8

Action Types • Unprotected Action: These actions lack all of the ACID properties except for consistency. – Example: A single disk write. • Protected Action: They have the ACID properties. – They do not externalize their results before they are completely done. – They can roll back if anything goes wrong before the normal end. – Once they have reached they normal end, what has happened remains. • Real Action: These actions affect the real, physical world in a way that is hard or impossible to reverse. – Example: Firing a missile. 9

Higher-Level Protected Actions (Transactions) • Since unprotected action can be undone, they can be included in a higher-level operation, which as a whole has the ACID properties. • Real actions need special treatment. The higherlevel operation must make sure that they are executed only if all enclosing protected actions have reached a state in which they will not decide to roll back. 10

Higher-Level Protected Actions (Transactions) BEGIN_WORK SELECT … /*unprotected action*/ UPDATE … /*unprotected action*/ DRILL_HOLE … INSERT … Defer execution of real action SELECT … IF (Condition) COMMIT_WORK; Now do it ELSE Don’t do it at all ROLLBACK_WORK; Note: The ACID properties hold for everything executed between BEGIN_WORK and COMMIT_WORK. 11

FLAT TRANSATIONS • A flat transaction contains an arbitrary number of simple actions; these actions may, in term, be either protected, real, or even unprotected, if necessary. • A flat transaction has only one layer of control. – The transaction will either survive together with everything else (commit), or it will be rolled back with everything else (abort). Limitation: There is no way of either committing or aborting parts of such transactions, or committing results in several steps, and so forth. 12

A Flat Transaction Example: Debit/Credit (1) exec sql CREATE TABLE accounts( Aid NUMERIC(9), Bid NUMERIC(9) FOREIGN KEY REFERENCES branches, Abalance filer NUMERIC(10), CHAR(48), PRIMARY KEY (Aid); 13

A Flat Transaction Example: Debit/Credit (2) /***main program with the invocation environment */ /* global declarations*/ exec sql BEGIN DECLARE SECTION; /* declare working storage */ long Aid, Bid Tid delta, abalance; /* account id, branch id, teller id, debit or */ /* credit amount, account balance */ exec sql END DECLARE SECTION; /* front end for the transaction program */ DCApplication() /* */ { read input msg; /* deal with request messages */ exec sql BEGIN WORK; /* start the flat transaction */ } Abalance = Do. Debit. Credit(Bid, Tid, Aid, delta); /* invoke transaction program */ send output msg; /* send response to terminal */ exec sql COMMIT WORK; /* successful end of transaction */ /* */ 14

A Flat Transaction Example: Debit/Credit (3) /* subroutine for doing the database accesses defined for TPC debit/credit transaction long Do. Debit. Credit(long Bid, long Tid, long Aid, long delta) */ { exec sql UPDATE accounts /* apply delta to the account balance SET Abalance = Abalance + : delta /* */ WHERE Aid = : Aid; /* */ /* read new value of balance */ FROM accounts /* */ WHERE Aid = : Aid /* */ /* apply delta to teller balance */ SET Tbalance = Tbalance + : delta /* */ WHERE Aid = : Aid; /* */ /* apply delta to branch balance */ SET Bbalance = Bbalance + delta /* */ WHERE Bid = : Bid; /* */ exec sql SELECT Abalance INTO : Abalance exec sql UPDATE tellers exec sql UPDATE branches exec sql INSERT INTO history (Tid, Bid, Aid, delta, time) VALUES (: Tid, : Bid, : Aid, : delta, CURRENT) /* insert parameters of transaction */ /* into application history */ return(Abalance); } 15

ROLLBACK Statements DCApplication() /* */ { receive input message; /* deal with request messages */ exec sql BEGIN WORK /* start the flat transaction */ Abalance = Do. Debit. Credit(Bid, Tid, Aid, delta); /* invoke transaction program if (Abalance < 0 && delta < 0) { exec sql ROLLBACK WORK; } else */ /* check if it a debit and account overdrawn */ /* if so: don’t do it */ /* this the good case: either credit or */ { /* enough money in account */ send output message; /* send response to terminal */ exec sql COMMIT WORK; /* successful end of transaction */ } } ROLLBACK makes sure that all the records are returned to their previous states. 16

Limitations of Flat Transactions (1) A one-layer control structure will not be able to model application structures that are significantly more complex. Example 1: Trip Planning • If there are no direct flights between two places, we must book a number of connecting flights. • If a partially done travel plan is not acceptable, there is no need to give back the reservation on all the flights. Note: Partial rollback is not possible for flat transactions. 17

Limitations of Flat Transactions (2) Example 2: Bulk Updates • At the end of a month, a bank has to modify all of its accounts by crediting or debiting the accumulated interest. • If the database process crashes after a large number of accounts have been updated, undoing these effects is undesirable. Note: Partial commit is useful here. 18

SPHERES OF CONTROL (1) • Spheres of Control (So. C) are based on a hierarchy of abstract data types (ADTs) which execute atomically Dynamically S A 1 B 2 C 1 created for controlling the commitment of A 1 A 2 B 3 B 4 B 1 C 2 B 5 D D is a noncommitable data item. 19

SPHERES OF CONTROL (2) • Spheres of Control come in two varieties: – One is statically established by structuring the system into a hierarchy of ADTs. – The other results from dynamic interactions among So. Cs on shared data, which cannot be committed yet. 20

Dependencies in Transaction Models (1) • Structural dependencies: These reflect the hierarchical organization of the system into ADTs of increasing complexity. Example: The commit of B 3 depends on the commit of A 2. The reason is the A 2 appears as an atomic action to the outside. S A 1 B 2 C 1 A 2 B 3 Dynamically created for controlling the commitment of A 1 B 4 C 2 B 5 D D is a noncommitable data item. 21

Dependencies in Transaction Models (2) • Dynamic dependencies: This type of dependency arises from the use of shared data. Example: A 2 depends on A 1 in the sense that A 2 can commit only if A 1 does. S A 1 B 2 C 1 A 2 B 3 Dynamically created for controlling the commitment of A 1 B 4 C 2 B 5 D D is a noncommitable data item. 22

Dynamic Behavior of So. C (1) 1. Beginning of scenario: At time t, a problem is discovered in the So. C B. Data from D 1 is determined to be the cause of the problem. 23

Dynamic Behavior of So. C (2) 2. Tracing dependencies backward in time: • • A dynamic So. C, F, is extended backward in time to contain the So. C that created the invalid data item D 1. F serves as the recovery environment. 24

Dynamic Behavior of So. C (3) 3. Again going forward in time to do recovery: • • The recovery So. C, F, is expanded forward in time. F must encompass all processes that have become dependent on any data produced by the process that created D 1. Note: Execution history must be kept for as long as control might still need to be exercised 25

State-Transition Diagram for a Flat Transaction NULL terminate BEGIN WORK COMMIT WORK terminate committed active ROLLBACK WORK aborted – Although it is useful to describe flat transactions as state machines, when describing phenomena for which it is not possible to define a priori a fixed number of states, this approach is not appropriate. – We will adapt the So. C model for describing transaction models. 26

Describing Transaction Models Transaction models are distinguished by different sets of rules • for creating the events that drive atomic actions, and • for the conditions under which the rules can take effect. 27

Describing Transaction Models Example S A 1 B 2 C 1 A 2 B 3 Dynamically created for controlling the commitment of A 1 B 4 C 2 B 5 D D is a noncommitable data item. • The event ROLLBACK WORK for atomic action B 3 can be triggered by the program running inside B 3, or by the abort of A 2 • The signal COMMIT WORK for B 3 is not sufficient to actually commit B 3, that can only happen if A 2 is ready to 28 commit too.

Graphical Representation of Transaction Models (1) Signal entries for the atomic action to perform a state transition Begin Commit Aborted A B C T Eternally unique identifier of the atomic action A Aborted State indicator of the action’s outcome C Commit Fig 4. 6: A graphical notation for general transaction models. For the graphical representation of a transaction model, each instance of an atomic action is depicted as a box with three entries at the top representing the signals for state transitions the action can receive, and two entries at the bottom representing the two (mutually exclusive) 29 final outcomes of the action.

Graphical Representation of Transaction Models (2) A B C A C A B C System A B A C C Trigger A B C A T C a) Transaction T is active: An abort of the system transaction will cause it to roll back, too. A B C T C b) Termination scenario 1: Transaction T has committed; all of its event ports are deactivated; the final state is highlighted. A C c) Termination scenario 2: Same as scenario 1, but T assumes the final abort sate. forbidden state or event Fig 4. 7: Describing flat transactions by means of the graphical notation. A flat transaction is nothing but an atomic action with only one structural dependency. This dependency says that if the system transaction aborts, the flat transaction if forced to abort, too. The system transaction is always in the active state, never commits, and aborts only as a result of a system crash. Once a flat transaction has committed, it stays around without any dependencies, only documenting which final result is related to its name. All incoming ports that cannot receive events and all final state that cannot be assumed are shaded. 30

Defining Transaction Models by Rules (1) <rule id>: <precondition> → <rule modifier list>, <signal list>, <state transition>. • The rule id specifies which signal port the arrow points to, and the precondition says where it comes from. – Whenever a signal from a state transition arrives, it is not executed until the preconditions are fulfilled. 31

Defining Transaction Models by Rules (2) <rule id>: <precondition> → <rule modifier list>, <signal list>, <state transition>. • <state transition> is essentially redundant, but it is kept for clarity. • <signal list> describes which signals are generated as part of the state transition. (The signals are simply the names of rules that are to be activated by the signal). 32

Defining Transaction Models by Rules (3) <rule id>: <precondition> → <rule modifier list>, <signal list>, <state transition>. • <rule modifier> is used to introduce additional arrows as they are needed, or to delete arrows that have become obsolete. <rule modifier> : : = +(<rule id>|<signal>) <rule modifier> : : = - (<rule id>|<signal>) <rule modifier> : : = delete(x), x is an atomic action. 33

The Rules for the Flat Transaction Model A B C A System C A B C System C A C Trigger A B C A T C a) Transaction T is active: An abort of the system transaction will cause it to roll back, too. A B C T C b) Termination scenario 1: Transaction T has committed; all of its event pots are deactivated; the final state is highlighted. A C c) Termination scenario 2: Same as scenario 1, but T assumes the final abort sate. SB(T): +(SA(system)|SA(T)), , BEGIN WORK SA(T): (delete(SB(T)), delete(SC(T))), , ROLLBACK WORK SC(T): (delete(SB(T)), delete(SA(T))), , COMMIT WORK • The first rule establishes the dependency from the system transaction and then starts the flat transaction itself. • The other rules specify the effects of the abort and commit events – since both resulting states are final states, the rules pertaining to the terminated transaction 34 must be removed.

Flat Transaction with Savepoints (1) BEGIN WORK (get transaction started) implicit SAVE WORK: 1 Action Work “covered” by savepoint number 2 SAVE WORK: 2 Action SAVE WORK: 3 Action SAVE WORK: 5 Action SAVE WORK: 6 SAVE WORK: 4 Action ROLLBACK WORK (2) SAVE WORK: 7 Work “covered” by savepoint number 5 Action ROLLBACK WORK (7) SAVE WORK: 8 Action COMMIT WORK 35

Flat Transaction with Savepoints (2) • A savepoint is established by invoking the SAVE WORK function, which causes the system to record the current state of processing. – This returns to the application program a handle that can subsequently be used to reestablish (return to) that savepoint. • A ROLLBACK does not affect the savepoint counter. • Advantage: Increasing Numbers monotonically allows the complete execution history to be maintained. • Disadvantage: It may lead to very unstructured programs. There is nothing that prevents the application program, after having generated savepoint number 8, from requesting a rollback to savepoint 4. 36

Graphical Representation of the Savepoint Model A B C A System A B C B A C A A B A C B A Trigger C C Trigger A B S 2 A C S 1 Trigger a) Transaction has started, establishing savepoint 1. C Trigger S 1 C C System Trigger S 1 A A System Trigger A C Trigger C S 2 C A C Trigger b) Next savepoint, S 2, has been taken. forbidden state or event c) Next savepoint, S 3, has been taken. A B C S 3 A C Trigger 37

Graphical Representation of the Savepoint Model (cont’d) • The basic idea is to regard the execution between two subsequent savepoints as an atomic action in the sense of So. C. • The completion of a savepoint creates a new atomic action that is dependent on its predecessor. 38

The Rules for the Savepoint Model First Savepoint: SB(S 1): +(SA(system)|SA (S 1)), , BEGIN WORK SA(R) : (R<S 1) , , ROLLBACK WORK SC(S 1): , , COMMIT WORK SS(S 1): +(SA(S 1)|SA (S 2)), SB(S 2), Intermediate Savepoint: 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), Note: • The delete clauses in the abort and commit rules look exactly like in the case of flat transactions, and are omitted here. • During a rollback, all the atomic actions on the way back are aborted. 39

Persistent Savepoints (1) • Making savepoints persistent implies that whenever a savepoint is taken, the state of the transaction must be kept in durable (persistent) storage. Restart Strategy: – The last unfinished savepoint interval is roll back, but – the state as of the previous successful persistent savepoint is reestablished. 40

Persistent Savepoints (2) Problem: • Conventional programming languages do not understand transactions: the database contents will return to the state as of the specified savepoint, but the local programming language variables will not. • We will discuss the programming discipline imposed by the use of savepoints later. 41

CHAINED TRANSACTIONS • Chained transactions are modeled by a sequence of atomic actions, executed one at a time. • Each transaction behaves like a flat transaction. • The commitment of one transaction and the beginning of the next are wrapped together into one atomic operation. The database context remains intact across the transaction boundaries. Effect: The amount of work lost after a crash can be minimized. 42

Rules for Chained Transactions A B C A System A B C C 1 C A B C C A C a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one. Trigger C A System A B C 2 Trigger A A B C A C 1 C A B C C 2 C A C b) The first transaction in the chain has been committed; the second one got started as part of commit of C 1. Now the second one is structurally dependent on “system”. Trigger Note: Either C 1 commits, then C 2 begins, or C 2 fails to begin, but then C 1 does not commit either. SB(Cn): +(SA(system)|SA (Cn)), , BEGIN WORK SA(Cn): , , ROLLBACK WORK SC(Sn): , SB(C n+1), COMMIT WORK 43

Chained Transaction vs. Savepoints • Since the chaining step irrevocably completes a transaction, roll back is limit to the currently active transaction • The COMMIT allows the application to free locks that it does not later need. • After a crash, the entire transaction is rolled back irrespective of any savepoints taken so far. The chained transaction schemes, on the other hand, can reestablish the state of the most recent commit. 44

Restart Processing in Chained Transactions From the application’s point of view, the whole chain is likely to be the sphere of control. What should actually happen in case one of the transactions in the chain aborts? Abort: the application has to determine how to fix that. Crash: the last transaction, after having been rollback, should be restarted. A B C A B System A C C 1 C A C Trigger A Trigger B C C 2 A B C A Restart A C B C 1’ A A C C Trigger C 45

Nested Transactions • A nested transaction is a tree of subtransactions. • A subtransaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. – Any subtransaction can finally commit only if the root transaction commits. Fig 4. 12: Nested transactions: the basic idea. A nested transaction is a tree of transactions. Starting at the root, each transaction can create lower-level transactions (subtransactions), which are embedded in the sphere of control of the parent. Transactions at 46 the leaf level are flat transactions, except that they lack the durability of non-nested flat transactions.

The Behavior of Nested Transactions (1) Commit rule: The commit of a subtransaction makes its results accessible only to the parent transaction. Rollback rule: The rollback of a subtransaction causes all of its subtransactions to rollback. – Subtransactions have only A, C, I, but not D. 47

The Behavior of Nested Transactions (2) Visibility rule: – All changes done by a substransaction become visible to the parent transaction upon the subtransaction’s commit. – All objects held by a parent transaction can be made accessible to its subtransactions. – Changes made by a subtransaction are not visible to its siblings, in case they execute concurrently. 48

Rules for Nested Transactions System A B System C A B T A System C A B T C a) Root transaction T is running. A T C A C Trigger Wait A B C A T 1 A C C A Wait B C T 2 C A C Wait b) Subtransaction T 1 has been started. A +(SA(Tk)|SA (Tkn)), , BEGIN WORK SA(Tkn): , , ROLLBACK WORK SC(Tkn): C(Tk) , , COMMIT WORK C T 11 A SB(Tkn): B C c) T 1 has created subtransaction T 11, and after that the root transaction starts another Wait subtransaction, T 2. Note: The arrows labeled “wait” correspond to the precondition 49 clauses in the rules.

Using Nested Transaction • There is a strong relationship between the concept of modularization in software engineering and the nested transaction mechanism. • Modular design takes care of the application structure and encapsulates local (dynamic) data structures; the transactions make sure that the global data used by these modules are isolated and recovered with the same granularity. 50

Transactional C • Transactional C is a programming language supported by the Encina TP monitor. • The run-time system of Transactional C supports the notion of nested transactions. Publications: • TP Monitor, TP-00 -D 146 • Transactional-C, Programmer Guide and reference, TP-00 -D 347 Company: Transarc Corp Pittsburgh, PA • Most current database systems do not rely on nested transactions for their own implementation. This is quite surprising because nesting the scope of commitment and backout is common places even in today’s SQL systems. 51

Emulating Nested Transactions by Savepoints Strategy: If at the beginning of a subtransaction a savepoint is generated, then rolling back to that savepoint has the same effect as an abort of the corresponding subtransaction. 52

Limitations of the Emulation of Nesting by Savepoints • The emulations is limited to systems where everything within a top-level transaction is executed sequentially. Reason: if subtransactions are allowed to execute in parallel, reestablishing the state of the savepoint associated with a transaction can affect arbitrary subtransactions, rather than only the subtree of the aborting transaction. • In nested transactions, subtransactions inherit locks from their parent transactions, and parent transactions counterinherit locks acquired by their subtransactions. This mechanism cannot be emulated by savepoints since there is only one flat transaction. 53

Distributed Transactions • A distributed transaction is typically a flat transaction that runs in a distributed environment. • The decomposition into distributed transaction does not reflect a hierarchical structure in the programs to be executed, but is induced by the placement of the data in the network. • In a distributed transaction, if a subtransaction commits, it forces all other subtransactions to commit. Note: By comparison, in a nested transaction, this is simply a local commit of that subtransactions. • Distributed subtransactions normally cannot roll back independently. Their decision to abort affects the entire transaction. 54

Distributed Transactions Distributed transactions are a restricted type of nested transactions that are used, for example, in distributed databases. For simplicity, only the case of one transaction is shown. Other subtransactions at any level are appended in exactly the same way. 55

Multi-Level Transactions A B C A B System A A Trigger B C A B a) Root transaction T is running. A C A b) Subtransaction N has been started. A C C c) Subtransaction N has committed and has installed its compensation transaction, CN, that will get started if T aborts. CN must commit. Trigger C A B C A N N A B T C B C Trigger A • • C A C System T C • B Trigger T A A System C A C C A B C CN C A C CN is the compensating transaction corresponding to the subtransaction N. It can semantically reverse what N has done. N can commit independently of T. When it does so, however, CN enters the scene. The abort of T is unconditionally linked to the commit of CN, which means CN must not fail. 56

Rules for Multi-Level Transactions • Rules for subtransaction N: SB(N): , , BEGIN WORK SA(N): , , ROLLBACK WORK SC(N): +(SA(T)|SB(CN)), , COMMIT WORK • Rules for the compensating transaction CN: SB(CN): +(SC(restart)|SB(CN’)), , BEGIN WORK SA(CN): , SB(CN’), ROLLBACK WORK SC(CN): delete(CN’), , COMMIT WORK Note: CN’ is an instance of CN. It ensures that the compensation continues after restart. 57

Advantage of Multi-Level Transactions Multi-level transactions are nested transactions with the ability to precommit the results of subtransactions. Disadvantage: The compensation actions can be very expensive. Advantage: The scheme of layering object implementation makes it possible to protect updates at lower layers by isolating higher-layer objects. 58

Advantage of Multi-Level Transactions - Example T INSERT When this operation is done the updated page is accessible to all transactions. However, the new tuples are not accessible as long as T has not finally committed. Conclusion: Since rollback is not a frequent operation, the advantages of having smaller units of commitment control will outweigh the cost of compensation by a wide margin. 59

Transaction Processing Context Programs frequently use contextual information in addition to the input parameters; this information is called context and is (potentially) modified every time the program is invoked. f(input_message, context) {output_message, context} 60

Transaction Processing Context Example exec sql DECLARE CURSOR c AS SELECT a, b, c FROM rel_a WHERE d = 10 ORDER BY a ASCENDING; exec sql OPEN CURSOR c; do { exec sql FETCH NEXT c INTO : a, : b, : c; /* perform computation*/ } while (SQLCODE == 0); exec sql CLOSE CURSOR c; Private context: The cursor position is a context that is private to the program. Global context: The contents of the database itself determine which “next” tuple can be retrieved. 61

DURABLE CONTEXT (1) Compute. Interest () { read (interest_rate); for (account_no = 1; account_no <= 1, 000; account_no++) {Single. Account(interest_rate, account_no); } reply (“done”) }; Single. Account (interest_rate, account_no) { BEGIN WORK /*do account update*/ COMMIT WORK; return (“OK”); } 62

DURABLE CONTEXT (2) Context can be volatile or durable: – An end-of-file pointer is volatile context because it needs not be recovered. – The context that says how far the sequence of Compute. Interest transactions has gotten must be durable because the program (reinstantiated version) and the database are out of synch after a crash. 63

THE MINI BATCH (1) A solution to the Compute. Interest problem: – Executing a sequence of transactions, each of them updating only a small number of accounts (called mini batch). – The application maintains its context as a database record. | a mini batch | Accounts 0 1 … n-1 n n+1 … i Last_account_done BATCHCONTEXT PROCESS n+1 Database stepsize … Note: Isolation is guaranteed only for the tuples the step transaction is accessing. 64

THE MINI BATCH (2) while (last_account_done < max_account_no) { EXEC SQL BEGIN WORK; /*initiate next mini-batch*/ EXEC SQL UPDATE accounts SET account_total = account_total * (1+ : interest_rate) WHERE account_no BETWEEN : last_account_done + 1 AND : last_account_done + : stepsize; EXEC SQL UPDATE batchcontext SET last_account_done = last_account_done + : stepsize; EXEC SQL COMMIT WORK; last_account_done = last_account_done + stepsize; } 65

LONG-LIVED TRANSACTIONS Long-Lived transactions can be found in the areas of engineering design, office automation, etc. Requirements: 1. 2. 3. Minimize lost work. It must be possible to split up bulk transactions in order to control the amount of lost work in case of a system crash. Recoverable computation. There must be ways to temporarily stop the computation without having to commit the results. Explicit control flow. Under all failure conditions, it must be possible to either proceed along the prespecified path or remove from the system what has been done so far. Providing adequate support for such applications is an area of active research. 66

SAGAS [Garci-Molina ’ 87] (1) • Saga is an extension of the notion of chained transactions. 1. It defines a chain of transactions as a unit of control. 2. It uses the compensation idea from multi-level transactions to make the entire chain atomic. 67

SAGAS [Garcia-Molina ’ 87] (2) A Saga has the following properties 1. Commit case: S 1, S 2, …, Si, … , Sn-1, Sn 2. Rollback scenario: S 1, S 2, …, Sj(abort), CSj-1… , CS 2, CS 1 A B C System A C Trigger A B C A S 1 A B C A S 2 C A B C A C CS 1 A B C CS 2 C A Trigger C S 3 A Trigger A B C C A backward chain of compensating transaction is established as the original chain proceeds in a forward direction. 68

COOPERATING TRANSACTIONS (1) Cooperative transactions allow for explicit interactions among collaborating users on shared (design) object. Transaction A do some design work show me object X Use object X Give back X X Transaction B granted create object X Time 69

COOPERATING TRANSACTIONS (2) • Prerelease upon request: object X is isolated until the surrounding So. C has decided to commit. However, there may be special transactions that are allowed to access it anyway, without creating a commit dependency on it. • Explicit return: The transaction that selectively releases commitment control knows who has access to the object and what kind of access is requested to the object, and it gets informed as soon as the object is returned to its original So. C. 70

RESEARCH TOPICS: Engineering Transaction Model • F. Bancilhon, W. Kim and H. F. Korth, “A Model of CAD Transaction, ” 11 th VLDB, 1985, pp. 25 -33. • Barghout and Kaiser, “Concurrency Control in Advanced Database Systems, ” ACM Computing Surveys. 23(3) 1991, p. 269. • H. Garcia-Molina and K. Salem, “Saga”, ACM SIGMOD, 1987, pp. 249 -259. • J. Klein and A. Reuter, “Migrating Transactions, ” Workshop on the Future Trends of Distributed Computing System, 1988, pp. 512 -520. • Y. Leu, A. K. Elmargarmrd and N-Boudriga, “Specification of Transactions for Advanced Database Applications, ” 1990, Purdue University, CSD-TR-1030. • A. Reuter, “Contracts: A means for Extending Control Beyond Transaction Boundaries, ” 3 rd Int’l Workshop on High Performance Transaction System. 71