Module 4 Isolation Concepts

1. Module 4 Isolation Concepts COP 6730

2. System State • The system state consists of objects related in certain ways. These relationships are best thought of as invariants about the objects. Examples: • Account balances must be positive • All managers must be employers and so must appear in the EMPLOYEE table • The system state is said to be consistent if it satisfies all these invariants.

3. Appearance of Isolation (1) Often, state must be made temporarily inconsistent while it is being transformed (by a transaction) to a new, consistent state. • Concurrent transaction execution must be controlled so that correct programs do not malfunction. • System try to control concurrency by providing the appearance of isolation (e.g., using locking).

4. Appearance of Isolation (2) Employee Transaction2 Delete an employee Transaction1 Manager Transaction3 Appearance of isolation

5. Dependency Model of Isolation The set of transactions {Ti} can run in parallel with no concurrency anomalies if their outputs are disjoint from one another’s inputs and outputs, i.e., Oi (Ij  Oj) =  for all i  j

6. Cannot help in this case Employee Transaction2 I am corrupting the data Transaction1 Manager Transaction3 Appearance of isolation The ACID property assumes that the transaction knows what it is doing to its data (i.e., program is correct)  If a transaction runs in isolation, it will correctly transform the system state.

7. Static Allocation - Early Systems • The transaction scheduler compares the new transaction’s needs to all the running transactions. • If there was a conflict, initiation of the new transaction is delayed until the conflicting transactions has completed. Problem: It is difficult to determine the inputs and outputs of a transaction before it runs. Example: Since a banking transaction potentially updates any record of the Account table, static allocation would probably reserve the entire table. → Result in serial execution of the transactions

8. Dynamic Allocation • Each transaction is viewed as a sequence of actions (rather then as an input-output set.) • When an action accesses a particular object, the object is dynamically allocated to that transaction. Advantage: Allocation at action level → more concurrency

9. More Concurrency I am blocked Employee Delete an employee Transaction2 Transaction1 Manager I can proceed Transaction3 Appearance of isolation

10. Versions of Objects • Transactions are sequences of actions operating on objects. • Objects go through a sequence of versions as they are written by these actions: • Nothing ever changes; rather, new versions of objects are created. Write Read <o,2> <o,1> <o,1> T2 T1 Different versions of object o

11. Transaction Dependency (1) • If a transaction reads an object, the transaction depends on that object version • If the transaction writes an object, the resulting object version depends on the writing transaction. I depends on T2 I depends on <0,1> Write Read <o,2> <o,1> <o,1> T2 T1 Since T2 may overwrite the data T1 depends on, we have a read-write dependency between T1 and T2

12. READ  WRITE dependency WRITE READ dependency WRITE  WRITE dependency Transaction Dependencies (1) • If a transaction reads an object, the transaction depends on that object version • If the transaction writes an object, the resulting object version depends on the writing transaction. Note: Only write actions create versions and dependencies.

13. Dependency Graph “T3 →T9” is not in the dependency graph Write T3 T3 T5 <o,2> T9 T7 Write T5 Write Read <o,4> <o,3> <o,3> T9 T7

14. Isolation Theorems Any dependency graph without cycles implies an isolated execution of the transactions. The transactions can be topologically sorted to make an equivalent execution history in which each transaction ran to completion before the next one began (i.e., isolated execution). Example: T1, T2, T4, T3 T1 T1 T2 T2 T4 T4 T3 T3 Equivalent

15. Three Bad Dependencies • There is no topological order for this set of transactions • concurrency anomalies. • Cycles take one of only three generic forms Lost Update, Dirty Read, and Unrepeatable Read T1 T2 T3

16. Lost Update Lost update: caused by WRITE->WRITE dependency T2 READ < 0, 1 > T1 WRITE < 0, 2> T2 WRITE < 0, 3 > T1’s write is ignored by T2 Lost update !

17. Dirty Read Dirty Read: caused by WRITE -> READ dependencies T2 WRITE < 0, 2 > T1 READ < 0, 2 > T2 WRITE < 0, 3 > Dirty read • T1 reads an object previously written by T2, then • T2 makes further changes to the object • T1 is using an outdated version of the object

18. Unrepeatable Read Unrepeatable Read: caused by READ -> WRITE dependencies T1 READ < 0, 1 > T2 WRITE < 0, 2 > T1 READ < 0, 2 > T1 reads an object twice: • once before T2 updates it, and • once after committed T2 has updated it. • The first read is not repeatable Unrepeatable read

19. A Cycle in all Three Forms Dirty read Lost update ! Unrepeatable read

20. ISOLATION Preventing the concurrency anomalies gives the effect of running transactions in isolation.

21. Dirty Outputs Outputs of a transaction are said to be uncommitted or dirty, if the transaction has not yet issued COMMIT WORK.

22. Isolated Transactions Transaction T is isolated from other transactions if: • T does not overwrite dirty data of other transactions. • T’s writes are neither read nor written by other transactions until COMMIT WORK • T does not read dirty data from other transactions. • Other transactions do not write any data read by T before T completes. Preclude lost update Prevent dirty reads Preclude lost update Prevent dirty reads Prevent unrepeatable read

23. Properties of Isolated Transactions • Each transaction reads a consistent input state. • Any execution of the system is equivalent to some serial execution (no concurrency anomalies) • None of the updates of committed transactions can be lost, and aborted transactions can be rerun.

24. NOTATIONS s = < a, b, c > : a sequence s || s : concatenation of two sequences s[i] : the ith element of sequence s < s[i] | predicate (s[i] ) > : a subsequence of s The system state, S, consists of an infinite set of named objects, each with a value. S is denoted{< name, value >}

25. Actions on Objects The system supports the following actions on these objects. To simplify the transaction model, • BEGIN, COMMIT, and ROLLBACK are defined in terms of the other actions (next slide), so that • only READ, WRITE, LOCK and UNLOCK actions remain.

26. COMMIT Example COMMIT action simply releases locks

27. ROLLBACK Example ROLLBACK action must • first undo all changes to the objects the transaction wrote, and • then issue the unlock statements

28. Well-Formed Transactions A transaction is said to be well-formed if • All its READ, WRITE, and UNLOCK actions are covered by locks (preceded by locking of the corresponding object), and • Each lock action is eventually followed by a corresponding UNLOCK action. READ and UNLOCK actions on O3 are not covered by an SLOCK or XLOCK WRITE action on O1 is not covered by an XLOCK Not well-formed !

29. 2-Phase Transactions A transaction is defined as 2-phase if all its lock actions precede all its UNLOCK actions. • Growing phase: acquiring locks • Shrinking Phase: releasing locks 2-Phase transaction Shrinking #locks Growing time

30. Transaction Histories • A history lists the order in which actions of a set of transactions were successfully completed. Example: • A transaction requests a lock at the beginning of the history but has to wait • The lock is finally granted near the end of the history • that lock request will appear near the end of the history • A history preserves the order of the actions in each of the transactions. Initial State History Trans. T2 action action action Trans. T1 Trans. T2 Trans. T3 action action action Trans. T1 Trans. T3 Another State

31. Serial History • The simplest histories first run all the actions of one transaction, then run all the actions of another to completion, and so on. • The transactions are isolated • Such one-transaction-at-a-time histories are called serial histories. • serial histories have no concurrency-induced inconsistency and no transaction sees dirty data

32. Legal Histories • Locking constraints the set of allowed histories. • Histories that obey the locking constraints are called Legal. This history cannot happen: T1 slock A T2 xlock A T2 write A T1 read A

33. Legal Histories - Examples • Histories are not constructed, they are a byproduct of the system behavior. • Locking systems only produce legal behavior. T2 would be made to wait until this time

34. States of a Transaction Begin Active Block Running Blocked Resume Restart (sometime) Reject Commit Committed Aborted

35. Active transactions Scheduler T1 Lock Compatibility Table Histories are not constructed, they are a byproduct of the system behavior. T2 next action serializable schedule Scheduler T3 actions in arriving order Legal history T4 bad action Abort the transactions Blocked Actions T5 Rejected Actions Rejected Actions: Actions that violate the 2-phase and/or Well-formed rules

36. An Analogy Scheduler An action of transaction 1 An action of transaction 2 An action of transaction 4 An action of transaction 3

37. Version of an Object • < T, a, o >: a step of the history. It denotes an action a by transaction T on object o. • V(o, k): The version of an object o at step k of a history. At step k of history H, object o has a version equal to the number of writes of that object before this step. V(o, k) = |{< t, aj, o >H | j<k and aj = WRITE}| Set size Action at Step j

38. Dependency Relation • Each history H for a set of transactions {Ti } defines a ternary dependency relationDEP(H): <T, < o, V(o,j) >, T> DEP(H) if a1 is a WRITE and a2 is a WRITE, or a1 is a WRITE and a2 is a READ, or a1 is a READ and a2 is a WRITE. where a1 and a2 are actions performed on the object o by T and T, respectively. • This definition captures the WRITEWRITE, WRITEREAD, and READWRITE dependencies. DEP(H): [SourceTrans, OID, ObjVersion, DestTrans]

39. Dependency Graph • The dependency relation for a history defines a directed dependency graph: • transactions are the nodes, and • object versions label the edges. • <T, < o, j >, T >  DEP(H)  the graph has an edge from node T to node T labeled by < o, j > T1 T T2 <o,j > T’

40. Isolated Histories • Two histories for the same set of transactions are equivalent if they have the same dependency relation, i.e., DEP(H) = DEP(H).  They have the same effect on the database • A history is said to be isolated if it is equivalent to a serial history.

41. Equivalent Histories - Example Serial history SH History H DEP(H) = DEP(SH) T1.1 T3.1 T1.2 T1.1 T1 T1.3 T3.2 T1.4 T2.1 T2.1 T1.2 T2.2 T3.3 T2 T3 T2.3 T2.2 T2.4 T3.4 T2.5 T4.1 T3.1 T2.3 T4 T3.2 T3.5 T3.3 T2.4 T3.4 T1.3 T3.5 T4.2 • DEP(H) = DEP(SH) • The corresponding transactions in H and SH read the same input and compute the same output • H and SH are equivalent • SH executes the transactions in isolation • H also executes the transactions in isolation T4.1 T2.5 T4.2 T4.3 T4.3 T4.4 T4.4 T4.5 T4.5 T1.4

42. Dependencies in a History • The dependencies of a history define a time order of the transactions. This ordering is denoted by the symbol “<<<.” • T<<< T if there is a path in the dependency graph from transaction T to transaction T, i.e., T<<< T if <T, o, T>  DEP(H), or /* direct */ T<<<HT and < T, o, T >  DEP(H) /* indirect */ • All equivalent histories define the same ordering. • Notations: BEFORE(T) = {T | T<<<T} AFTER(T) = {T | T<<<T} T is called a wormhole transaction if T BEFORE(T)  AFTER(T) A T B T AFTER(T) Z T’ Y X T BEFORE(T)

43. WORMHOLES ARE NOT ISOLATED • T<<<T<<<T indicates a cycle in the dependency graph. • Since a dependency graph with cycles is not equivalent to any serial history, a history with wormholes is not isolated.

44. WORMHOLE TRANSACTIONS No wormhole T3,T4,T5,T6 transactions are wormhole transactions  No cycles!  Cycles!Note: Two transactions not related by <<< maybe arbitrarily scheduled with respect to each other, e.g., T2 and T4

45. Wormhole Theorem A history is isolated if, and only if, it has no wormhole transactions.

46. Locking Theorems • Locking theorem: If all transactions are well-formed and two-phase, then any legal history will be isolated. Analogy: • Traffic lights provide a “safety” mechanism • If all drivers are good citizen, traffic lights prevent accidents • Locking theorem (converse): If a transaction is not well-formed or is not two-phase, then it is possible to write another transaction such that the resulting pair is a wormhole. Analogy: If there are bad drivers, then accidents can occur

47. Rollback Theorem An update transaction that does an UNLOCK and then a ROLLBACK is not two-phase.

48. Wormhole Theorem: Proof Wormhole Theorem: A history is isolated if, and only if, it has no wormhole transactions. We need to prove two things: • History H is isolated  no wormholes (proof is by contradiction – next page) • H has no wormholes  H is isolated (proof is by induction)

49. Wormhole Theorem: Proof (cont’d) 1. History H is Isolation  no wormholes (proof is by contradiction) • Suppose H is an isolated history of {Ti | i = 1,.., n} • H is equivalent to some serial history SH = T7 || T4 || T9 || … || Tn • Rename the corresponding transactions in H and SH to obtain the following transaction index pattern for SH: SH = T1 || T2 || T3 || … || Tn (1) • Suppose that H has wormhole (contradiction): T <<< T <<< … Tj <<<H Ti <<<… <<< T <<< T, wherei is the minimum transaction index in this wormhole. • By the minimality of i, we must have Ti <<<SH Tj according to (1) • Tj<<<SH Ti is impossible. • Tj<<<H Ti is not possible (because H and SH are equivalent) • H has no wormholes. Not possible

50. Wormhole Theorem: Proof (cont’d) • H has no wormholes  H is isolated: This proof is by induction on the number of transactions, n, that appear in the history, H. (1) If n < 2, then any history is a serial history  any history is isolated. (2) Suppose the induction hypothesis is true for n - 1 transactions i.e., “H has no wormholes  H is isolated”is true for n-1 transactions (3) Considering some history H of n transactions that has no wormholes, prove that H is isolated (see next page)