1. 1 CS216 Advanced Database Systems Shivnath Babu Notes 12: Concurrency Control (II)

2. 2 How to enforce serializable schedules? Option 1: run system, recording P(S); at end of day, check for P(S) cycles and declare if execution was good

3. 3 Option 2: prevent P(S) cycles from occurring T 1 T 2 …..T n Scheduler DB How to enforce serializable schedules?

4. 4 A locking protocol Two new actions: lock (exclusive):l i (A) unlock:u i (A) scheduler T 1 T 2 lock table

5. 5 Rule #1: Well-formed transactions T i : … l i (A) … p i (A) … u i (A)...

6. 6 Rule #2 Legal scheduler S = …….. l i (A) ………... u i (A) ……... no l j (A)

7. 7 What schedules are legal? What transactions are well-formed? S1 = l 1 (A)l 1 (B)r 1 (A)w 1 (B)l 2 (B)u 1 (A)u 1 (B) r 2 (B)w 2 (B)u 2 (B)l 3 (B)r 3 (B)u 3 (B) S2 = l 1 (A)r 1 (A)w 1 (B)u 1 (A)u 1 (B) l 2 (B)r 2 (B)w 2 (B)l 3 (B)r 3 (B)u 3 (B) S3 = l 1 (A)r 1 (A)u 1 (A)l 1 (B)w 1 (B)u 1 (B) l 2 (B)r 2 (B)w 2 (B)u 2 (B)l 3 (B)r 3 (B)u 3 (B) Exercise:

8. 8 What schedules are legal? What transactions are well-formed? S1 = l 1 (A)l 1 (B)r 1 (A)w 1 (B)l 2 (B)u 1 (A)u 1 (B) r 2 (B)w 2 (B)u 2 (B)l 3 (B)r 3 (B)u 3 (B) S2 = l 1 (A)r 1 (A)w 1 (B)u 1 (A)u 1 (B) l 2 (B)r 2 (B)w 2 (B)l 3 (B)r 3 (B)u 3 (B) S3 = l 1 (A)r 1 (A)u 1 (A)l 1 (B)w 1 (B)u 1 (B) l 2 (B)r 2 (B)w 2 (B)u 2 (B)l 3 (B)r 3 (B)u 3 (B) Exercise:

9. 9 Schedule F T1 T2 l 1 (A);Read(A) A A+100;Write(A);u 1 (A) l 2 (A);Read(A) A Ax2;Write(A);u 2 (A) l 2 (B);Read(B) B Bx2;Write(B);u 2 (B) l 1 (B);Read(B) B B+100;Write(B);u 1 (B)

10. 10 Schedule F T1 T2 25 25 l 1 (A);Read(A) A A+100;Write(A);u 1 (A) 125 l 2 (A);Read(A) A Ax2;Write(A);u 2 (A) 250 l 2 (B);Read(B) B Bx2;Write(B);u 2 (B) 50 l 1 (B);Read(B) B B+100;Write(B);u 1 (B) 150 250 150 A B

11. 11 Rule #3 Two phase locking (2PL) for transactions T i = ……. l i (A) ………... u i (A) ……... no unlocks no locks

12. 12 # locks held by Ti Time Growing Shrinking Phase Phase

13. 13 Schedule G delayed

14. 14 Schedule G delayed

15. 15 Schedule G delayed

16. 16 Schedule H (T 2 reversed) delayed

17. 17 Assume deadlocked transactions are rolled back –They have no effect –They do not appear in schedule E.g., Schedule H = This space intentionally left blank!

18. 18 Next step: Show that rules #1,2,3  conflict- serializable schedules

19. 19 Conflict rules for l i (A), u i (A): l i (A), l j (A) conflict l i (A), u j (A) conflict Note: no conflict,,...

20. 20 Theorem Rules #1,2,3  conflict (2PL) serializable schedule To help in proof: Definition Shrink(Ti) = SH(Ti) = first unlock action of Ti

21. 21 Lemma Ti  Tj in S  SH(Ti) < S SH(Tj) Proof of lemma: Ti  Tj means that S = … p i (A) … q j (A) …; p,q conflict By rules 1,2: S = … p i (A) … u i (A) … l j (A)... q j (A) … By rule 3: SH(Ti) SH(Tj) So, SH(Ti) < S SH(Tj)

22. 22 Proof: (1) Assume P(S) has cycle T 1  T 2  …. T n  T 1 (2) By lemma: SH(T 1 ) < SH(T 2 ) <... < SH(T 1 ) (3) Impossible, so P(S) acyclic (4)  S is conflict serializable Theorem Rules #1,2,3  conflict (2PL) serializable schedule

23. 23 Beyond this simple 2PL protocol, it is all a matter of improving performance and allowing more concurrency…. –Shared locks –Multiple granularity –Inserts, deletes, and phantoms –Other types of C.C. mechanisms

24. 24 Shared locks So far: S =...l 1 (A) r 1 (A) u 1 (A) … l 2 (A) r 2 (A) u 2 (A) … Do not conflict Instead: S=... ls 1 (A) r 1 (A) ls 2 (A) r 2 (A) …. us 1 (A) us 2 (A)

25. 25 Lock actions l-t i (A): lock A in t mode (t is S or X) u-t i (A): unlock t mode (t is S or X) Shorthand: u i (A): unlock whatever modes T i has locked A

26. 26 Rule #1 Well formed transactions T i =... l-S 1 (A) … r 1 (A) … u 1 (A) … T i =... l-X 1 (A) … w 1 (A) … u 1 (A) …

27. 27 What about transactions that read and write same object? Option 1: Request exclusive lock T i =...l-X 1 (A) … r 1 (A)... w 1 (A)... u(A) …

28. 28 Option 2: Upgrade (E.g., need to read, but don’t know if will write…) T i =... l-S 1 (A) … r 1 (A)... l-X 1 (A) …w 1 (A)...u(A)… Think of - Get 2nd lock on A, or - Drop S, get X lock What about transactions that read and write same object?

29. 29 Rule #2 Legal scheduler S =....l-S i (A) … … u i (A) … no l-X j (A) S =... l-X i (A) … … u i (A) … no l-X j (A) no l-S j (A)

30. 30 A way to summarize Rule #2 Compatibility matrix Comp S X S true false Xfalse false

31. 31 Rule # 3 2PL transactions No change except for upgrades: (I) If upgrade gets more locks (e.g., S  {S, X}) then no change! (II) If upgrade releases read (shared) lock (e.g., S  X) - can be allowed in growing phase

32. 32 Proof: similar to X locks case Theorem Rules 1,2,3  Conf.serializable for S/X locks schedules

33. 33 Lock types beyond S/X Examples: (1) increment lock (2) update lock

34. 34 Example (1): increment lock Atomic increment action: IN i (A) {Read(A); A  A+k; Write(A)} IN i (A), IN j (A) do not conflict! A=7 A=5A=17 A=15 IN i (A) +2 IN j (A) +10 IN j (A) +2 IN i (A)

35. 35 CompSXI S X I

36. 36 CompSXI STFF XFFF IFFT

37. 37 Update locks

38. 38 Solution If T i wants to read A and knows it may later want to write A, it requests update lock (not shared)

39. 39 CompSXU S X U New request Lock already held in

40. 40 CompSXU STFT XFFF U TorF FF -> symmetric table? New request Lock already held in

41. 41 Note: object A may be locked in different modes at the same time... S 1 =...l-S 1 (A)…l-S 2 (A)…l-U 3 (A)… l-S 4 (A)…? l-U 4 (A)…? To grant a lock in mode t, mode t must be compatible with all currently held locks on object

42. 42 How does locking work in practice? Every system is different (E.g., may not even provide CONFLICT-SERIALIZABLE schedules) But here is one (simplified) way...

43. 43 (1) Don’t trust transactions to request/release locks (2) Hold all locks until transaction commits # locks time Sample Locking System:

44. 44 Ti Read(A),Write(B) l(A),Read(A),l(B),Write(B)… Read(A),Write(B) Scheduler, part I Scheduler, part II DB lock table

45. 45 Lock table Conceptually A  B C ... Lock info for B Lock info for C If null, object is unlocked Every possible object

46. 46 But use hash table: A If object not found in hash table, it is unlocked Lock info for A A... H

47. 47 Lock info for A - example tran mode wait? Nxt T_link Object:A Group mode:U Waiting:yes List: T1 S no T2 U no T3X yes  To other T3 records

48. 48 What are the objects we lock? ? Relation A Relation B... Tuple A Tuple B Tuple C... Disk block A Disk block B... DB

49. 49 Locking works in any case, but should we choose small or large objects? If we lock large objects (e.g., Relations) –Need few locks –Low concurrency If we lock small objects (e.g., tuples,fields) –Need more locks –More concurrency

50. 50 We can have it both ways!! Ask any janitor to give you the solution... hall Stall 1Stall 2Stall 3Stall 4 restroom

51. 51 Example R1 t1t1 t2t2 t3t3 t4t4 T 1 (IS) T 1 (S), T 2 (S)

52. 52 Example R1 t1t1 t2t2 t3t3 t4t4 T 1 (IS) T 1 (S), T 2 (IX) T 2 (IX)

53. 53 Multiple granularity CompRequestor IS IX S SIX X IS Holder IX S SIX X

54. 54 Multiple granularity CompRequestor IS IX S SIX X IS Holder IX S SIX X TTTTF F F F FFFFF FFFT FTFT FFTT

55. 55 ParentChild can belocked in IS IX S SIX X P C

56. 56 ParentChild can belocked in IS IX S SIX X P C IS, S IS, S, IX, X, SIX [S, IS] not necessary X, IX, [SIX] none

57. 57 Rules (1) Follow multiple granularity comp function (2) Lock root of tree first, any mode (3) Node Q can be locked by Ti in S or IS only if parent(Q) locked by Ti in IX or IS (4) Node Q can be locked by Ti in X,SIX,IX only if parent(Q) locked by Ti in IX,SIX (5) Ti is two-phase (6) Ti can unlock node Q only if none of Q’s children are locked by Ti

58. 58 Exercise: Can T 2 access object f 2.2 in X mode? What locks will T 2 get? R1 t1t1 t2t2 t3t3 t4t4 T 1 (IX) f 2.1 f 2.2 f 3.1 f 3.2 T 1 (IX) T 1 (X)

59. 59 Exercise: Can T 2 access object f 2.2 in X mode? What locks will T 2 get? R1 t1t1 t2t2 t3t3 t4t4 T 1 (X) f 2.1 f 2.2 f 3.1 f 3.2 T 1 (IX)

60. 60 Exercise: Can T 2 access object f 3.1 in X mode? What locks will T 2 get? R1 t1t1 t2t2 t3t3 t4t4 T 1 (S) f 2.1 f 2.2 f 3.1 f 3.2 T 1 (IS)

61. 61 Exercise: Can T 2 access object f 2.2 in S mode? What locks will T 2 get? R1 t1t1 t2t2 t3t3 t4t4 T 1 (IX) f 2.1 f 2.2 f 3.1 f 3.2 T 1 (SIX) T 1 (X)

62. 62 Exercise: Can T 2 access object f 2.2 in X mode? What locks will T 2 get? R1 t1t1 t2t2 t3t3 t4t4 T 1 (IX) f 2.1 f 2.2 f 3.1 f 3.2 T 1 (SIX) T 1 (X)

63. 63 Insert + delete operations Insert A Z ...

64. 64 Modifications to locking rules: (1) Get exclusive lock on A before deleting A (2) At insert A operation by Ti, Ti is given exclusive lock on A

65. 65 Phantoms Still have a problem: Phantoms Example: relation R (E#,name,…) constraint: E# is key use tuple locking RE#Name…. o155Smith o275Jones

66. 66 T 1 : Insert into R T 2 : Insert into R T 1 T 2 S 1 (o 1 ) S 2 (o 1 ) S 1 (o 2 ) S 2 (o 2 ) Check Constraint Insert o 3 [04,Kerry,..] Insert o 4 [04,Bush,..]...

67. 67 Solution Use multiple granularity tree Before insert of node Q, lock parent(Q) in X mode R1 t1t1 t2t2 t3t3

68. 68 Back to example T 1 : Insert T 2 : Insert T 1 T 2 X 1 (R) Check constraint Insert U(R) X 2 (R) Check constraint Oops! e# = 04 already in R! delayed

69. 69 Instead of using R, can use index on R: Example: R Index 0<E#<100 Index 100<E#<200 E#=2E#=5 E#=107 E#=109...

70. 70 This approach can be generalized to multiple indexes...

71. 71 Next: Tree-based concurrency control Validation concurrency control

72. 72 Example A B C D EF all objects accessed through root, following pointers T 1 lock  can we release A lock if we no longer need A??

73. 73 Idea: traverse like “Monkey Bars” A B C D EF T 1 lock

74. 74 Why does this work? Assume all T i start at root; exclusive lock T i  T j  T i locks root before T j Actually works if we don’t always start at root Root Q T i  T j

75. 75 Rules: tree protocol (exclusive locks) (1) First lock by T i may be on any item (2) After that, item Q can be locked by T i only if parent(Q) locked by T i (3) Items may be unlocked at any time (4) After T i unlocks Q, it cannot relock Q

76. 76 Tree-like protocols are used typically for B-tree concurrency control E.g., during insert, do not release parent lock, until you are certain child does not have to split Root

77. 77 Validation Transactions have 3 phases: (1) Read –all DB values read –writes to temporary storage –no locking (2) Validate –check if schedule so far is serializable (3) Write –if validate ok, write to DB

78. 78 Key idea Make validation atomic If T 1, T 2, T 3, … is validation order, then resulting schedule will be conflict equivalent to S s = T 1 T 2 T 3...

79. 79 To implement validation, system keeps two sets: FIN = transactions that have finished phase 3 (and are all done) VAL = transactions that have successfully finished phase 2 (validation)

80. 80 Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} time T 2 start T 2 validated T 3 validated T 3 start  = 

81. 81 T 2 finish phase 3 Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} time T 2 start T 2 validated T 3 validated T 3 start  =  allow T 3 start

82. 82 Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 validated finish T 2 BAD: w 3 (D) w 2 (D)

83. 83 finish T 2 Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 validated allow finish T 2

84. 84 Validation rules for T j : (1) When T j starts phase 1: ignore(T j )  FIN (2) at T j Validation: if check (T j ) then [ VAL  VAL U {T j }; do write phase; FIN  FIN U {T j } ]

85. 85 Check (T j ): For T i  VAL - IGNORE (T j ) DO IF [ WS(T i )  RS(T j )   OR T i  FIN ] THEN RETURN false; RETURN true; Is this check too restrictive ?

86. 86 Improving Check(T j ) For T i  VAL - IGNORE (T j ) DO IF [ WS(T i )  RS(T j )   OR ( T i  FIN AND WS(T i )  WS(T j )   )] THEN RETURN false; RETURN true;

87. 87 Exercise: T: RS(T)={A,B} WS(T)={A,C} V: RS(V)={B} WS(V)={D,E} U: RS(U)={B} WS(U)={D} W: RS(W)={A,D} WS(W)={A,C} start validate finish

88. 88 Validation (also called optimistic concurrency control) is useful in some cases: - Conflicts rare - System resources plentiful - Have real time constraints

89. 89 Summary Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Tree (index) protocols - Validation