1. 1 CSE232A: Database System Principles More Concurrency Control and Transaction Processing

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

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

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

5. 5 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  = 

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

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

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

9. 9 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 } ]

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

11. 11 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;

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

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

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

15. 15 Chapter 10 More on transaction processing Topics (which I doubt we’ll get to all of them): Cascading rollback, recoverable schedule Deadlocks –Prevention –Detection View serializability Long transactions (nested, compensation)

16. 16 Example:T j T i W j (A) r i (A) Commit T i Abort T j Concurrency control & recovery … … … … … …  Cascading rollback (Bad!)

17. 17 Schedule is conflict serializable T j T i But not recoverable

18. 18 Need to make “final’ decision for each transaction: –commit decision - system guarantees transaction will or has completed, no matter what –abort decision - system guarantees transaction will or has been rolled back (has no effect)

19. 19 To model this, two new actions: C i - transaction T i commits A i - transaction T i aborts

20. 20... Back to example: T j T i W j (A) r i (A) C i  can we commit here?

21. 21 Definition T i reads from T j in S (T j  S T i ) if (1) w j (A) < S r i (A) (2) a j < S r i (A) (< : does not precede ) (3) If w j (A) < S w k (A) < S r i (A) then a k < S r i (A)

22. 22 Definition Schedule S is recoverable if whenever T j  S T i and j  i and C i  S then C j < S C i

23. 23 Note: in transactions, reads and writes precede commit or abort  If C i  T i, then r i (A) < C i w i (A) < C i  If A i  T i, then r i (A) < A i w i (A) < A i Also, one of Ci, Ai per transaction

24. 24 How to achieve recoverable schedules?

25. 25  With 2PL, hold write locks to commit (strict 2PL) T j T i W j (A) C j u j (A) r i (A)...

26. 26  With validation, no change!

27. 27 S is recoverable if each transaction commits only after all transactions from which it read have committed. S avoids cascading rollback if each transaction may read only those values written by committed transactions.

28. 28 S is strict if each transaction may read and write only items previously written by committed transactions. Avoids cascading rollback RC ACR ST SERIAL

29. 29 Where are serializable schedules? Avoids cascading rollback RC ACR ST SERIAL

30. 30 Examples Recoverable: –w 1 (A) w 1 (B) w 2 (A) r 2 (B) c 1 c 2 Avoids Cascading Rollback: –w 1 (A) w 1 (B) w 2 (A) c 1 r 2 (B) c 2 Strict: –w 1 (A) w 1 (B) c 1 w 2 (A) r 2 (B) c 2 Assumes w 2 (A) is done without reading

31. 31 Deadlocks Detection –Wait-for graph Prevention –Resource ordering –Timeout –Wait-die –Wound-wait

32. 32 Deadlock Detection Build Wait-For graph Use lock table structures Build incrementally or periodically When cycle found, rollback victim T1T1 T3T3 T2T2 T6T6 T5T5 T4T4 T7T7

33. 33 Resource Ordering Order all elements A 1, A 2, …, A n A transaction T can lock A i after A j only if i > j Problem : Ordered lock requests not realistic in most cases

34. 34 Timeout If transaction waits more than L sec., roll it back! Simple scheme Hard to select L

35. 35 Wait-die Transactions given a timestamp when they arrive …. ts(T i ) T i can only wait for T j if ts(T i )< ts(T j )...else die

36. 36 T 1 (ts =10) T 2 (ts =20) T 3 (ts =25) wait Example: wait?

37. 37 Wound-wait Transactions given a timestamp when they arrive … ts(T i ) T i wounds T j if ts(T i )< ts(T j ) else T i waits “Wound”: T j rolls back and gives lock to T i

38. 38 User/Program commands Lots of variations, but in general Begin_work Commit_work Abort_work

39. 39 Nested transactions User program: Begin_work; If results_ok, then commit work else abort_work...

40. 40 Nested transactions User program: Begin_work; If results_ok, then commit work else {abort_work; try something else…} If results_ok, then commit work else abort_work...

41. 41 Parallel Nested Transactions T 1 : begin-work parallel: T 11 :begin_work commit_work T 12 :begin_work commit_work... T1T1 T 11 T 12 T1T1

42. 42 Locking What are we really locking?

43. 43 Example: T i Read record r 1 Read record r 1 do record locking Modify record r 3...

44. 44 But underneath: Disk pages R3R3 R1R1 R2R2 record id If we lock all data involved in read of R1, we may prevent an update to R2 (which may require reorganization within block)

45. 45 Solution: view DB at two levels Top level: record actions record locks undo/redo actions — logical e.g., Insert record(X,Y,Z) Redo: insert(X,Y,Z) Undo: delete

46. 46 Low level: deal with physical details latch page during action (release at end of action)

47. 47 Note: undo does not return physical DB to original state; only same logical state e.g., Insert R3Undo (delete R3) R1 R2 R1 R2 R3

48. 48 Related idea: Sagas Long running activity: T 1, T 2,... T n Each step/trasnaction Ti has a compensating transaction Ti-1 Semantic atomicity: execute one of –T 1, T 2,... T n –T 1, T 2,... T n-1 T -1 n-1, T -1 n-2,... T -1 1 –T 1, T 2,... T n-2 T -1 n-2, T -1 n-3,... T -1 1 –T 1, T -1 1 –nothing...

49. 49 Summary Cascading rollback Recoverable schedule Deadlock –Prevention –Detectoin Nested transactions Multi-level view