1 Concurrency Control Conflict serializability Two phase locking Optimistic concurrency control Source: slides by Hector Garcia-Molina

2 Concurrently Executing Transactions T1T2…Tn DB (consistency constraints)

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 Schedule A 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); AB

5 Schedule B 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); AB

6 Schedule C 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); AB

7 Schedule D 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); AB

8 Schedule E 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); AB Same as Schedule D but with new T2’

9 uWant schedules that are “good”, regardless of winitial state and wtransaction semantics uOnly 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 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 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) uas a matter of fact, T 2 must precede T 1 in any equivalent schedule, i.e., T 2  T 1

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

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 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 What about concurrent actions? T1 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 So net effect is either u S=…r 1 (X)…w 2 (B)… or u S=…w 2 (B)…r 1 (X)…

17 uAssume equivalent to either r 1 (A) w 2 (A) orw 2 (A) r 1 (A) u  low level synchronization mechanism uAssumption 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 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 Definition A schedule is conflict serializable if it is conflict equivalent to some serial schedule.

20 Nodes: transactions in S Arcs: Ti  Tj whenever wthere is an action of Ti in S wthere is an action of Tj later in S wboth actions are on same database element wand at least one is a write Precedence graph P(S) (S is schedule )

21 Exercise: uWhat 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) uIs S serializable?

22 Another Exercise: uWhat is P(S) for S = w 1 (A) r 2 (A) r 3 (A) w 4 (A) ?

23 Characterizing Conflict Serializability Theorem: A schedule is conflict serializable if and only if its precedence graph has no cycles.

24 How to enforce serializable schedules? Option 1: urun system, recording P(S) uat end of day, check for cycles in P(S) udeclare execution good if no cycles else bad

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

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

27 Rule #1: Well-formed ("consistent") transactions T i : … l i (A) … p i (A) … u i (A)... p i (A) is either a read or a write

28 Rule #2 Legal scheduler S = …….. l i (A) ………... u i (A) ……... no l j (A) I.e., only one transaction has a DB element locked at any time.

29 uWhat 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: uWhat schedules are legal?

30 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)

31 Schedule F T1 T 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) A B

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

33 # locks held by Ti Time Growing Shrinking Phase Phase

34 Schedule G delayed

35 Schedule G delayed

36 Schedule G delayed

37 Schedule H (T 2 reversed) delayed Deadlock!

38 uAssume deadlocked transactions are rolled back wThey have no effect wThey do not appear in schedule E.g., Schedule H = This space intentionally left blank!

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

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

41 2PL Ensures Conflict-Serializability Theorem: Every schedule produced by two-phase locking, i.e., wevery read and write is preceded by a lock and followed by an unlock wno DB item is simultaneously locked by more than one transaction wfor each transaction, the last lock precedes the first unlock is conflict-serializable.

42 uBeyond this simple 2PL protocol, it is all a matter of improving performance and allowing more concurrency…. wShared locks wIncrement locks wMultiple granularity wOther types of concurrency control mechanisms

43 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)

44 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

45 Rule #1 Well formed transactions T 1 =... l-S 1 (A) … r 1 (A) … u 1 (A) … T 1 =... l-X 1 (A) … w 1 (A) … u 1 (A) … I.e., must hold a shared lock to read and must hold an exclusive lock to write

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

47 Option 2: Upgrade (E.g., need to read, but don’t know if will write…) T 1 =... 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?

48 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) I.e., an element can be locked exclusively by one transaction or by several in shared mode, but not both

49 A way to summarize Rule #2 Compatibility matrix S X S true false Xfalse false

50 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

51 2PL Ensures Conflict- Serializability With Shared Locks Theorem: Every schedule produced by two-phase locking, modified to handle shared locks, is conflict-serializable.

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

53 Example (1): increment lock uAtomic increment action: IN i (A) {Read(A); A  A+k; Write(A)} uIN 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)

54 CompatibilitySXI MatrixS X I

55 CompatibilitySXI MatrixSTFF XFFF IFFT

56 Update locks

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

58 Comp. MatrixSXU S X U New request Lock already held in

59 Comp. MatrixSXU STFT XFFF U TorF FF -> symmetric table? New request Lock already held in

60 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)…? uTo grant a lock in mode t, mode t must be compatible with all currently held locks on object

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

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

63 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

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

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

66 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

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

68 uLocking works in any case, but should we choose small or large objects? uIf we lock large objects (e.g., Relations) wNeed few locks wLow concurrency uIf we lock small objects (e.g., tuples,fields) wNeed more locks wMore concurrency

69 We can have it both ways!! Called multi-granularity locking.

70 Optimistic Concurrency Control uLocking is pessimistic -- assumes something bad will try to happen and prevents it uInstead assume conflicts won't occur in the common case, then check at the end of a transaction wtimestamping wvalidation

71 Timestamping uAssign a "timestamp" to each transaction uKeep track of the timestamp of the last transaction to read and write each DB element uCompare these values to check for serializability uAbort transaction if there is a violation

72 Validation Transactions have 3 phases: (1) Read wall DB values read wwrites to temporary storage wno locking (2) Validate wcheck if schedule so far is serializable (3) Write wif validate ok, write to DB

73 Comparison uSpace usage of optimistic CC is about the same as locking: roughly proportional to number of DB elements accessed uOptimistic CC is useful when wconflicts are rare wsystem resources are plentiful wthere are real-time constraints