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

ICS214BNotes 062 Topics: Cascading rollback, recoverable schedule Deadlocks –Prevention –Detection

ICS214BNotes 063 Example: T j T i W j (A) r i (A) Commit T i Abort T j Schedule is conflict serializable (Tj  Ti) but not recoverable Cascading rollback (Bad!) Concurrency control & recovery … … … … … …

ICS214BNotes 064 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: –A i - transaction T i aborts –C i - transaction T i commits

ICS214BNotes 065 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, only one of Ci, Ai can appear in a transaction

ICS214BNotes Back to example: T j T i W j (A) r i (A) C i  can we commit here? No, since Ti reads from Tj, which may abort.

ICS214BNotes 067 Definition “read from” 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)

ICS214BNotes 068 Definition Schedule S is recoverable if each transaction commits only after each transaction from which it has read has committed. Formally: whenever T j  S T i and j  i and C i  S, then C j < S C i

ICS214BNotes 069 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

ICS214BNotes 0610 Question: How to achieve recoverable schedules?

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

ICS214BNotes 0612 With validation, no change!

ICS214BNotes 0613 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.

ICS214BNotes 0614 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

ICS214BNotes 0615 Containment: Avoids cascading rollback RC ACR ST SERIAL SERIALIZABLE

ICS214BNotes 0616 Next topic: Deadlocks Easy detection: timeout Wait-for graphs Prevention: Resource ordering Detection by timestamps –Wait-die –Wound-wait

ICS214BNotes 0617 Detection: Timeout If transaction waits more than L sec., roll it back! Simple scheme Hard to select L

ICS214BNotes 0618 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 T1T1 T2T2

ICS214BNotes 0619 Deadlock Detection Build Wait-For graph, check acyclicity Use lock table structures Build incrementally or periodically When cycle found, rollback victims T1T1 T3T3 T2T2 T6T6 T5T5 T4T4 T7T7

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

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

ICS214BNotes 0622 T 1 (ts =10) T 2 (ts =20) T 3 (ts =25) wait Wait-Die: Example wait?

ICS214BNotes 0623 T 1 (ts =22) T 2 (ts =20) T 3 (ts =25) wait(A) Second Example requests A: wait for T 2 or T 3 ? Note: ts between 20 and 25.

ICS214BNotes 0624 T 1 (ts =22) T 2 (ts =20) T 3 (ts =25) wait(A) Second Example (continued): wait(A) One option: T 1 waits just for T 3, transaction holding lock. But if T 2 gets lock, T 1 will have to die!

ICS214BNotes 0625 T 1 (ts =22) T 2 (ts =20) T 3 (ts =25) wait(A) Second Example (continued): wait(A) Another option: T 1 only gets A lock after T 2, T 3 complete, so T 1 waits for both T 2, T 3  T 1 dies right away!

ICS214BNotes 0626 T 1 (ts =22) T 2 (ts =20) T 3 (ts =25) wait(A) Second Example (continued): wait(A) Yet another option: T 1 preempts T 2, so T 1 only waits for T 3 ; T 2 then waits for T 3 and T 1...  T 2 may starve? redundant arc

ICS214BNotes 0627 Wound-wait scheme Younger xacts wait for older xacts T i can wait for T j if ts(T i ) > ts(T j ) 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

ICS214BNotes 0628 T 1 (ts =25) T 2 (ts =20) T 3 (ts =10) wait Example: 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

ICS214BNotes 0629 T 1 (ts =15) T 2 (ts =20) T 3 (ts =10) wait(A) Second Example: requests A: wait for T 2 or T 3 ? Note: ts between 10 and 20.

ICS214BNotes 0630 T 1 (ts =15) T 2 (ts =20) T 3 (ts =10) wait(A) Second Example (continued): wait(A) One option: T 1 waits just for T 3, transaction holding lock. But when T 2 gets lock, T 1 waits for T 2 and wounds T 2.

ICS214BNotes 0631 T 1 (ts =15) T 2 (ts =20) T 3 (ts =10) wait(A) Second Example (continued): wait(A) Another option: T 1 only gets A lock after T 2, T 3 complete, so T 1 waits for both T 2, T 3  T 2 wounded right away!

ICS214BNotes 0632 T 1 (ts =15) T 2 (ts =20) T 3 (ts =10) wait(A) Second Example (continued): wait(A) Yet another option: T 1 preempts T 2, so T 1 only waits for T 3 ; T 2 then waits for T 3 and T 1...  T 2 is spared!

ICS214BNotes 0633 Why do the timestamp-based schemes prevent deadlocks? Reasons: for both schemes, xacts are “ordered” and cycles are prevented in the wait-for graph

ICS214BNotes 0634 Next Topics: Long transactions (nested, compensation)

ICS214BNotes 0635 User/Program commands Lots of variations, but in general Begin_work Commit_work Abort_work

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

ICS214BNotes 0637 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...

ICS214BNotes 0638 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

ICS214BNotes 0639 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.