1. 1 CSE232A: Database System Principle Concurrency Control

2. 2 Chapter 9Concurrency Control T1T2…Tn DB (consistency constraints)

3. 3 Example: T1:Read(A)T2:Read(A) A  A+100A  A  2Write(A)Read(B) B  B+100B  B  2Write(B) Constraint: A=B

4. 4 Serial Schedule A (“good” by definition) T1T2 Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); AB25 125 250 250

5. 5 Serial Schedule B (equally “good”) T1T2 Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); AB25 50 150 150

6. 6 Interleaved Schedule C (good because it is equivalent to A) T1T2 Read(A); A  A+100 Write(A); Read(A);A  A  2; Write(A); Read(B); B  B+100; Write(B); Read(B);B  B  2; Write(B); AB25 125 250 125 250250 Scoping “equivalence” is tricky; for now think that A and C are equivalent because if they start from same initial values they end up with same results

7. 7 Interleaved Schedule D (bad!) T1T2 Read(A); A  A+100 Write(A); Read(A);A  A  2; Write(A); Read(B);B  B  2; Write(B); Read(B); B  B+100; Write(B); AB25 125 250 50 150 250150

8. 8 Schedule E (good by “accident”) T1T2’ Read(A); A  A+100 Write(A); Read(A);A  A  1; Write(A); Read(B);B  B  1; Write(B); Read(B); B  B+100; Write(B); AB25 125 25 125125 Same as Schedule D but with new T2’ The accident being the particular semantics

9. 9 Want schedules that are “good”, I.e., equivalent to serial regardless of –initial state and –transaction semantics Only look at order of read and writes Example: SC=r 1 (A)w 1 (A)r 2 (A)w 2 (A)r 1 (B)w 1 (B)r 2 (B)w 2 (B)

10. 10 SC’=r 1 (A)w 1 (A) r 1 (B)w 1 (B)r 2 (A)w 2 (A)r 2 (B)w 2 (B) T 1 T 2 Example: SC=r 1 (A)w 1 (A)r 2 (A)w 2 (A)r 1 (B)w 1 (B)r 2 (B)w 2 (B)

11. 11 However, for SD: SD=r 1 (A)w 1 (A)r 2 (A)w 2 (A) r 2 (B)w 2 (B)r 1 (B)w 1 (B) as a matter of fact, T 2 must precede T 1 in any equivalent schedule, i.e., T 2  T 1 And vice versa

12. 12 T 1 T 2 SD cannot be rearranged into a serial schedule SD is not “equivalent” to any serial schedule SD is “bad” T 2  T 1 Also, T 1  T 2

13. 13 Returning to Sc SC=r 1 (A)w 1 (A)r 2 (A)w 2 (A)r 1 (B)w 1 (B)r 2 (B)w 2 (B) T 1  T 2 T 1  T 2  no cycles  SC is “equivalent” to a serial schedule (in this case T 1,T 2 )

14. 14 Concepts Transaction: sequence of r i (x), w i (x) actions Conflicting actions: r 1(A) w 2(A) w 1(A) w 2(A) r 1(A) w 2(A) Schedule: represents chronological order in which actions are executed Serial schedule: no interleaving of actions or transactions

15. 15 What about concurrent actions? Ti issuesSystemInput(X) t  x read(x,t)issuescompletes input(x) time T2 issues write(B,S) System issues input(B) completes B  S System issues output(B) completes

16. 16 So net effect is either S=…r 1 (x)…w 2 (B)… or S=…w 2 (B)…r 1 (x)…

17. 17 Assume equivalent to either r 1 (A) w 2 (A) orw 2 (A) r 1 (A)  low level synchronization mechanism Assumption called “atomic actions” What about conflicting, concurrent actions on same object? start r 1 (A)end r 1 (A) start w 2 (A) end w 2 (A) time

18. 18 Definition S 1, S 2 are conflict equivalent schedules if S 1 can be transformed into S 2 by a series of swaps on non-conflicting actions.

19. 19 Definition A schedule is conflict serializable if it is conflict equivalent to some serial schedule.

20. 20 Nodes: transactions in S Arcs: Ti  Tj whenever - p i (A), q j (A) are actions in S - p i (A) < S q j (A) - at least one of p i, q j is a write Precedence graph P(S) (S is schedule )

21. 21 Exercise: What is P(S) for S = w 3 (A) w 2 (C) r 1 (A) w 1 (B) r 1 (C) w 2 (A) r 4 (A) w 4 (D) Is S serializable?

22. 22 Lemma S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof: Assume P(S 1 )  P(S 2 )   T i, T j : T i  T j in S 1 and not in S 2  S 1 = …p i (A)... q j (A)… p i, q j S 2 = …q j (A)…p i (A)... conflict  S 1, S 2 not conflict equivalent

23. 23 Note: P(S 1 )=P(S 2 )  S 1, S 2 conflict equivalent Counter example: S 1 =w 1 (A) r 2 (A) w 2 (B) r 1 (B) S 2 =r 2 (A) w 1 (A) r 1 (B) w 2 (B)

24. 24 Theorem P(S 1 ) acyclic  S 1 conflict serializable (  ) Assume S 1 is conflict serializable   S s : S s, S 1 conflict equivalent  P(S s ) = P(S 1 )  P(S 1 ) acyclic since P(S s ) is acyclic

25. 25 (  ) Assume P(S 1 ) is acyclic Transform S 1 as follows: (1) Take T 1 to be transaction with no incident arcs (2) Move all T 1 actions to the front S 1 = ……. q j (A)……. p 1 (A)….. (3) we now have S 1 = (4) repeat above steps to serialize rest! T 1 T 2 T 3 T 4 Theorem P(S 1 ) acyclic  S 1 conflict serializable

26. 26 How to enforce serializable schedules? Option 1: run system, recording P(S); check for P(S)cycles and declare if execution was good; or abort transactions as soon as they generate a cycle

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

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

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

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

31. 31 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:

32. 32 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:

33. 33 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)

34. 34 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

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

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

37. 37 Schedule G delayed

38. 38 Schedule G delayed

39. 39 Schedule G delayed

40. 40 Schedule H (T 2 reversed) delayed

41. 41 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!

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

43. 43 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,,...

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

45. 45 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)

46. 46 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

47. 47 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

48. 48 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)

49. 49 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

50. 50 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) …

51. 51 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) …

52. 52 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?

53. 53 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)

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

55. 55 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

56. 56 Proof: similar to X locks case Detail: l-t i (A), l-r j (A) do not conflict if comp(t,r) l-t i (A), u-r j (A) do not conflict if comp(t,r) Theorem Rules 1,2,3  Conf.serializable for S/X locks schedules

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

58. 58 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)

59. 59 CompSXI S X I

60. 60 CompSXI STFF XFFF IFFT

61. 61 Update locks

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

63. 63 CompSXU S X U New request Lock already held in -> symmetric table?

64. 64 CompSXU STFT XFFF U F FF New request Lock already held in

65. 65 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

66. 66 How does locking work in practice? Every system is different But here is one (simplified) way...

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

68. 68 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

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

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

71. 71 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

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

73. 73 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

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

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

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

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

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

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

80. 80 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

81. 81 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

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

83. 83 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

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

85. 85 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 [99,Gore,..] Insert o 4 [99,Bush,..]...

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

87. 87 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# = 99 already in R! delayed

88. 88 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...

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

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

91. 91 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??

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

93. 93 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

94. 94 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

95. 95 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