1. 1 More Transaction Management Concurrency control and recovery Resolving deadlocks Logical logging Source: slides by Hector Garcia-Molina

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

3. 3 uSchedule is conflict serializable: T j T i uBut not recoverable

4. 4 uNeed to make “final" decision for each transaction: wcommit decision - system guarantees transaction will or has completed, no matter what wabort decision - system guarantees transaction will or has been rolled back (has no effect)

5. 5 To model this, two new actions: uC i - transaction T i commits uA i - transaction T i aborts uEach transaction T i has exactly one, either C i or A i uEvery read and write of T i precedes the C i (or A i )

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

7. 7 Definition T i reads from T j in S (denoted T j  S T i ) if 1.there is a write w j (A) in S that is followed by a read r i (A) in S 2.there is no abort of T j in S before the r i (A) in S 3.if there is a write to A in S between w j (A) and r i (A) by another transaction T k, then T k aborts before the r i (A)

8. 8 Definition Schedule S is recoverable if whenever Ti reads from another transaction Tj, Ti does not commit until after Tj commits.

9. 9 How to achieve recoverable schedules?

10. 10  With 2PL, hold write locks until transaction commits (strict 2PL) T j T i W j (A) C j u j (A) r i (A)...

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

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

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

14. 14 Examples uRecoverable: ww 1 (A) w 1 (B) w 2 (A) r 2 (B) c 1 c 2 uAvoids Cascading Rollback: ww 1 (A) w 1 (B) w 2 (A) c 1 r 2 (B) c 2 uStrict: ww 1 (A) w 1 (B) c 1 w 2 (A) r 2 (B) c 2

15. 15 More Examples SERIALIZABLE Avoids cascading rollback RC ACR ST SERIAL w 1 (A) w 1 (B) w 2 (A) r 2 (B) c 2 c 1 w 2 (A) w 1 (B) w 1 (A) r 2 (B) c 1 c 2

16. 16 Deadlocks uDetection wWait-for graph uPrevention wResource ordering wTimeout wWait-die wWound-wait

17. 17 Deadlock Detection uBuild Wait-For graph uUse lock table structures uBuild incrementally or periodically uWhen cycle found, rollback victim T1T1 T3T3 T2T2 T6T6 T5T5 T4T4 T7T7

18. 18 Resource Ordering uOrder all elements A 1, A 2, …, A n uEach transaction must acquire locks on elements in this order (i.e., T cannot lock Aj before Ai if j > i) Problem : Ordered lock requests not realistic in most cases

19. 19 Timeout uIf transaction waits more than L sec., roll it back! uSimple scheme uHard to select L

20. 20 Wait-die uEach transaction T i is given a timestamp when it starts, denoted ts(T i ) uSuppose T i requests a lock currently held by T j uif ts(T i )< ts(T j ) then T i waits for T j (older waits for younger) else T i dies (aborts) (younger dies) uIf Ti dies then it later restarts with the same timestamp

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

22. 22 Wound-wait uEach transaction T i is given a timestamp when it starts, denoted ts(T i ) uSuppose T i requests a lock currently held by T j uIf ts(T i )< ts(T j ) then T i wounds T j (younger yields lock to older) else T i waits (younger waits for older) “Wound”: T j rolls back and gives lock to T i uIf T j dies then later it restarts with the same timestamp

23. 23 T 1 (ts =25) T 2 (ts =20) T 3 (ts =10) wait Example: wait? (Note that timestamps are different than in previous example) No.

24. 24 Comparing Deadlock Management Schemes uWait-die and Wound-wait ensure no starvation (unlike the others) uWait-die tends to roll back more transactions than Wound-wait but they tend to have done less work uWait-die and Wound-wait are easier to implement than waits-for graph uWaits-for graph technique only aborts transactions if there really is a deadlock (unlike the others)

25. 25 Managing Rollbacks Using Locking What are we really locking?

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

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

28. 28 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 Low level: deal with physical details

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

30. 30 Logging Logical Actions uLogical action typically span one block uUndo/redo log entry specifies undo/redo logical action Challenge: making actions idempotent Example (bad): redo insert  key inserted multiple times!