1 / 39

ICS 214B: Transaction Processing and Distributed Data Management

ICS 214B: Transaction Processing and Distributed Data Management. Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions Professor Chen Li. Topics: Cascading rollback, recoverable schedule Deadlocks Prevention Detection. Concurrency control & recovery.

alma
Download Presentation

ICS 214B: Transaction Processing and Distributed Data Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICS 214B: Transaction Processing and Distributed Data Management Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions Professor Chen Li

  2. Topics: • Cascading rollback, recoverable schedule • Deadlocks • Prevention • Detection Notes 06

  3. Concurrency control & recovery Example: Tj Ti Wj(A) ri(A) Commit Ti Abort Tj Schedule is • conflict serializable (Tj Ti) • but not recoverable • Cascading rollback (Bad!) … … … … … … Notes 06

  4. 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) • Need two more actions: • Ai - transaction Ti aborts • Ci - transaction Ti commits Notes 06

  5. Note: in transactions, reads and writes precede commit or abort  If Ci  Ti, then ri(A) < Ci wi(A) < Ci  If Ai  Ti, then ri(A) < Ai wi(A) < Ai • Also, only one of Ci, Ai can appear in a transaction Notes 06

  6. Back to example: Tj Ti Wj(A) ri(A) Cican wecommit here? No, since Ti reads from Tj, which may abort. ... ... ... ... Notes 06

  7. Definition “read from” Ti reads from Tj in S (Tj STi) if (1) wj(A)<S ri(A) (2) Aj <S ri(A) (< : does not precede) (3) If wj(A)<Swk(A)<Sri(A) then Ak <S ri(A) Notes 06

  8. Definition Schedule S is recoverable if each transaction commits only after each transaction from which it has read has committed. Formally: whenever TjS Ti and j  i and Ci  S, then Cj <S Ci Notes 06

  9. Recoverability and serializability are orthogonal • Recoverable and serializable: w1(A), w1(B), w2(A), r2(B), C1, C2 • Recoverable but not serializable: w2(A),w1(B),w1(A),r2(B), c1, c2 • Serializable but not recoverable: w1(A), w1(B), w2(A), r2(B), c2, c1 Notes 06

  10. Question: How to achieve recoverable schedules? Notes 06

  11. With 2PL, hold write locks to commit (strict 2PL) Tj Ti Wj(A) Cj uj(A) ri(A) ... ... ... ... ... ... ... Notes 06

  12. With validation, no change! Notes 06

  13. S is recoverable (RC) if each transaction commits only after all transactions from which it read have committed. • S avoids cascading rollback (ACR)if each transaction may read only those values written by committed transactions. • i.e., forbids reading of uncommitted data • Example: • Both RC and ACR: w1(A),w1(B), w2(A), c1, r2(B), c2 • RC but not ACR: w1(A), w1(B), w2(A), r2(B), c2, c1 • Every ACR schedule is RC. Notes 06

  14. S is strict(ST) if each transaction may read and write only items previously written by committed transactions. • Every serial schedule is ST • Example: ST but not serial w2(B), w1(A), r2(D), c2, r1(C), c1 Notes 06

  15. Containment: SERIALIZABLE RC Avoids cascading rollback ST SERIAL ACR Notes 06

  16. Next topic: Deadlocks • Easy detection: timeout • Wait-for graphs • Prevention: Resource ordering • Detection by timestamps • Wait-die • Wound-wait Notes 06

  17. Detection: Timeout • If transaction waits more than L sec., roll it back! • Simple scheme • Hard to select L Notes 06

  18. Wait-for graph • An arc from T1 to T2: • T2 is holding a lock on item A • T1 is waiting for a lock on A • T1 cannot get the lock unless T2 releases its lock T2 T1 Notes 06

  19. Deadlock Detection • Build Wait-For graph, check acyclicity • Use lock table structures • Build incrementally or periodically • When cycle found, rollback victims T5 T2 T1 T7 T4 T6 T3 Notes 06

  20. Prevention: Resource Ordering • Order all elements A1, A2, …, An • Transaction T can lock Ai after Aj only if i > j Problem : Ordered lock requests not realistic in most cases Notes 06

  21. Detection: Timestamps • Transaction Ti is given a timestamp ts(Ti) when arrives • Two schemes: • Wait-Die: • Older (earlier) xacts can wait for younger xacts, i.e., • Ti can only wait for Tj if ts(Ti)< ts(Tj), • Otherwise, Ti needs to “die” (i.e., is rolled back) • Wound-wait • Younger xacts wait for older xacts Notes 06

  22. wait? Wait-Die: Example T1 (ts =10) T2 (ts =20) T3 (ts =25) wait wait Notes 06

  23. Second Example requests A: wait for T2 or T3? T1 (ts =22) T2 (ts =20) T3 (ts =25) Note: ts between 20 and 25. wait(A) Notes 06

  24. Second Example (continued): One option: T1 waits just for T3, transaction holding lock. But if T2 gets lock, T1 will have to die! T1 (ts =22) T2 (ts =20) T3 (ts =25) wait(A) wait(A) Notes 06

  25. Second Example (continued): Another option: T1 only gets A lock after T2, T3 complete, so T1 waits for both T2, T3 T1 dies right away! T1 (ts =22) T2 (ts =20) T3 (ts =25) wait(A) wait(A) wait(A) Notes 06

  26. Second Example (continued): Yet another option: T1 preempts T2, so T1 only waits for T3; T2 then waits for T3 and T1...  T2 may starve? T1 (ts =22) T2 (ts =20) T3 (ts =25) wait(A) wait(A) wait(A) redundant arc Notes 06

  27. Wound-wait scheme • Younger xacts wait for older xacts • Ti can wait for Tj if ts(Ti) > ts(Tj) • Otherwise, Ti “wounds” Tj • Usually the wound is fatal, then Tj releases the lock, and is rolled back • If Tj has finished when Ti wounds Tj, then Tj releases the block, and is NOT rolled back Notes 06

  28. wait Example: wait T1 (ts =25) T2 (ts =20) T3 (ts =10) wait • When T2 wounds T1 • T1 needs to release the lock • If T1 is not finished  fatal, rolled back • Otherwise, no need to be rolled back Notes 06

  29. Second Example: requests A: wait for T2 or T3? T1 (ts =15) T2 (ts =20) T3 (ts =10) Note: ts between 10 and 20. wait(A) Notes 06

  30. Second Example (continued): One option: T1 waits just for T3, transaction holding lock. But when T2 gets lock, T1 waits for T2 and wounds T2. T1 (ts =15) T2 (ts =20) T3 (ts =10) wait(A) wait(A) Notes 06

  31. Second Example (continued): Another option: T1 only gets A lock after T2, T3 complete, so T1 waits for both T2, T3 T2 wounded right away! T1 (ts =15) T2 (ts =20) T3 (ts =10) wait(A) wait(A) wait(A) Notes 06

  32. Second Example (continued): Yet another option: T1 preempts T2, so T1 only waits for T3; T2 then waits for T3 and T1...  T2 is spared! T1 (ts =15) T2 (ts =20) T3 (ts =10) wait(A) wait(A) wait(A) Notes 06

  33. Why do the timestamp-based schemes prevent deadlocks? • Reasons: for both schemes, xacts are “ordered” and cycles are prevented in the wait-for graph Notes 06

  34. Next Topics: • Long transactions (nested, compensation) Notes 06

  35. User/Program commands Lots of variations, but in general • Begin_work • Commit_work • Abort_work Notes 06

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

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

  38. T1 T1 T12 T11 Parallel Nested Transactions T1: begin-work parallel: T11: begin_work commit_work T12: begin_work commit_work commit_work ... ... ... ... Notes 06

  39. Compensating transactions • For a transaction A, its compensating transaction A-1 “undo” the effects of A • Reason: • Transactions: A, B1, B2 of the same “big” xact • Suppose A commits, B1 commits, but B2 aborts • We need to roll back the effects of A and B by running B1-1 and A-1 • Formally: • Let B1B2…Bn be any sequence of actions and compensating xacts • For any database state D, the following two sequences of actions leave the database in the same state: • B1B2…Bn • A B1B2…Bn A-1 • Not all transactions are compensatable. Notes 06

More Related