1 Notes 09: Transaction Processing Slides are modified from the CS 245 class slides of Hector Garcia- Molina

Reading Chapter 10.1, 10.2 Chapter 11.1 – 11.3,

Transactions A sequence of operations on one or more data items. Fundamental assumption: a transaction when run on a consistent state and without interference with other transactions will leave the database in a consistent state. 3

Termination of Transactions Commit: guarantee that all of the changes of the transaction are permanent Abort: guarantee that none of the effects of the transaction are permanent –Reason for abort: user, transaction, system failure 4

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

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

7 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

8 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

9 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

10 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

11 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’

12 Want schedules that are “good”, 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)

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

14 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

15 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

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

17 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

Transaction A transaction T is a partial order, denoted by <, where –T  { r[x], w[x]:x is a data item}  {a, c} –a  T iff c  T –Suppose t is either a or c, than for any other operation p  T, p<t 18

Complete History A complete history H over T={T 1, …, T n } is a partial order, < H, where –H=  (i=1, …, n) Ti –<H   (i=1, …, n) <I –For any pair of conflicting operations p, q, either p < H q or q< H p 19

20 Conflict equivalent histories H 1, H 2 are conflict equivalent if –Both are over the same transactions and have the same operations, and –They order the conflicting operations the same way, i.e., if H 1 can be transformed into H 2 by a series of swaps on non- conflicting actions.

21 Conflict Serializable History A history is conflict serializable if it is conflict equivalent to some serial history.

View Equivalence Let T1: x=x+1, T2: x=x*3 Let initially x=5 Serial histories: –T1, T2, final value x=18 –T2, T1, final value x=16 No efficient algorithm to guarantee view serializability 22

23 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/ history)

24 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?

25 Lemma S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof: Assume P(S 1 )  P(S 2 )   T i : 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

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

27 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

28 (  ) 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

29 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

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

What to do with aborted transactions? If a transaction T aborts, the DBMS must: –Undo all values written by T –Abort all transactions that read any value written by T (avoid dirty read) –Ensure recoverability Strict execution: a transaction can read or write only committed values. 31

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

33 Rule #1: Well-formed transactions T i : … l i (A) … p i (A) … u i (A)... That is, if the transaction 1) locks an item in an appropriate mode before accessing it and 2) unlocks each item that it locks.

34 Rule #2 Legal scheduler S = …….. l i (A) ………... u i (A) ……... If the transaction does not lock any item if it is already locked in a conflicting mode. no l j (A)

35 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:

36 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:

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

38 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

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

40 # locks held by Ti Time Growing Shrinking Phase Phase

41 Schedule G delayed

42 Schedule G delayed

43 Schedule G delayed

44 Schedule H (T 2 reversed) delayed

45 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!

46 Next step: Show that rules #1,2,3  conflict- serializable schedules Advantage: Easy to guarantee these properties!

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

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

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

50 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

Problem with 2PL Deadlock Deadlock detection, prevention, avoidance 51

52 Variations of 2PL Conservative 2PL:each transaction must acquire all its locks before any of the operations are submitted –Adv: no deadlocks –Disadv: need read and write sets in advance –Starvation

Variations of 2PL Strict 2PL: transactions release their locks after either commit or abort –Adv: transaction has all the locks needed, recoverable histories, avoid cascading aborts –Disadv: cannot avoid deadlocks, performance tradeoffs 53

Deadlock Avoidance 1. Order database object in linear order and transactions must acquire locks in this order –Adv.: avoid deadlock –Disadv.: need order in advance and need to know all the operations in advance 54

Deadlock Avoidance 2. Time-out: if a transaction waits for a lock longer than a predefined time period then the transaction aborts –Adv.: no information about the transactions is needed in advance –Disadv.: potentially cascading aborts 55

Deadlock Avoidance 3. Wait-for-graph: keep a record on which transactions waits for which transaction to release a lock. If cycle then there is a deadlock. –Adv.: simplified administration –Disadv.: which transaction to abort? 56

57 Beyond the variations of 2PL protocol, it is all a matter of improving performance and allowing more concurrency…. –Shared locks –Multiple granularity (database -> cell) –Inserts, deletes and phantoms –Other types of C.C. mechanisms

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

59 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

60 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) …

61 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) …

62 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?

63 Rule #2 Legal scheduler S =....l-S i (A) … … u i (A) … no l-X j (A) (but can have l-S j (A) ) S =... l-X i (A) … … u i (A) … no l-X j (A) no l-S j (A)

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

65 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

66 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

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

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

69 CompSXI S X I

70 CompSXI STFF XFFF IFFT How about adding another column and row for decrement operations?

71 Update locks

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

73 CompSXU S X U New request Lock already held in

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

75 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

Locking Granularity Database Relation Attributes Tuple 76 Database hierarchy (tree)

Locking Granularity Tree: –Each node has a unique parent –Each node in the hierarchy can be locked –A requested node is locked in an explicit mode, e.g., exclusive lock Implicit lock: –When a parent node is locked in an exclusive lock, each descendent is locked in an implicit lock 77

Intentional Lock Must be assigned top-down Indicate intention (e.g., IS, IX) Must tag both the ancestors and the descendents of a node 78

Locks IS: intentional share the requested node –Descendents: can be explicitly locked in S or IS mode IX: intentional exclusive access to the requested node –Descendents: can be locked explicitly in X, S, SIX, IS, and IX 79

Locks S: shared access to the requested node –Descendents: implicit shared locks on all X: exclusive access to the requested node –Descendents: implicit x-locks on all SIX: shared and intentional exclusive access on the requested node –Descendents: implicit shared lock on all, and explicit lock in X, SIX, or IX mode 80

Compatibility ISIXSSIXX IS IX S SIX X 81

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

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

84 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

Next class Distributed Database Systems 85