ICS 214B: Transaction Processing and
Distributed Data Management
Lecture 6: Cascading Rollbacks, Deadlocks, and
Long Transactions
Professor Chen Li
1
Topics:
• Cascading rollback, recoverable schedule
• Deadlocks
– Prevention
– Detection
ICS214B
Notes 06
2
Concurrency control & recovery
Ti
Wj(A)
……
Tj
…
Example:
…
… …
ri(A)
Commit Ti
Abort Tj
Schedule is
• conflict serializable (Tj Ti)
• but not recoverable
• Cascading rollback (Bad!)
ICS214B
Notes 06
3
• 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
ICS214B
Notes 06
4
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
ICS214B
Notes 06
5
Back to example:
ri(A)
...
...
Wj(A)
Ti
...
...
Tj
Ci 
can we commit here?
No, since Ti reads from Tj, which may abort.
ICS214B
Notes 06
6
Definition “read from”
Ti reads from Tj in S (Tj S Ti) if
(1) wj(A) <S ri(A)
(2) Aj <S ri(A)
(< :
does not precede)
(3) If wj(A) <S wk(A) <S ri(A) then
Ak <S ri(A)
ICS214B
Notes 06
7
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
ICS214B
Notes 06
8
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
ICS214B
Notes 06
9
Question: How to achieve recoverable
schedules?
ICS214B
Notes 06
10
Tj
Ti
...
... ... ... ...
With 2PL, hold write locks to
commit (strict 2PL)
...
Wj(A)
...
Cj
uj(A)
ICS214B
ri(A)
Notes 06
11
With validation, no change!
ICS214B
Notes 06
12
• 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.
ICS214B
Notes 06
13
• 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
ICS214B
Notes 06
14
• Containment:
SERIALIZABLE
RC
ST
Avoids SERIAL
cascading rollback
ACR
ICS214B
Notes 06
15
Next topic: Deadlocks
•
•
•
•
Easy detection: timeout
Wait-for graphs
Prevention: Resource ordering
Detection by timestamps
– Wait-die
– Wound-wait
ICS214B
Notes 06
16
Detection: Timeout
• If transaction waits more than L sec.,
roll it back!
• Simple scheme
• Hard to select L
ICS214B
Notes 06
17
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
T1
ICS214B
T2
Notes 06
18
Deadlock Detection
•
•
•
•
Build Wait-For graph, check acyclicity
Use lock table structures
Build incrementally or periodically
When cycle found, rollback victims
T1
T4
ICS214B
T5
T2
T3
T6
Notes 06
T7
19
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
ICS214B
Notes 06
20
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
ICS214B
Notes 06
21
Wait-Die: Example
T1
wait
(ts =10)
T2
wait?
wait
(ts =20)
T3
(ts =25)
ICS214B
Notes 06
22
Second Example
T1
requests A: wait for T2 or T3?
(ts =22)
T2
Note: ts between
20 and 25.
wait(A)
(ts =20)
T3
(ts =25)
ICS214B
Notes 06
23
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
wait(A)
wait(A)
(ts =20)
T3
(ts =25)
ICS214B
Notes 06
24
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)
wait(A)
T2
(ts =20)
wait(A)
wait(A)
T3
(ts =25)
ICS214B
Notes 06
25
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)
wait(A)
T2
wait(A)
wait(A)
T3
redundant arc
(ts =25)
ICS214B
(ts =20)
Notes 06
26
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
ICS214B
Notes 06
27
Example: T1
wait
(ts =25)
T2
wait
wait
(ts =20)
T3
(ts =10)
• 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
ICS214B
Notes 06
28
Second Example:
T1
requests A: wait for T2 or T3?
(ts =15)
T2
Note: ts between
10 and 20.
wait(A)
(ts =20)
T3
(ts =10)
ICS214B
Notes 06
29
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
wait(A)
(ts =20)
wait(A)
T3
(ts =10)
ICS214B
Notes 06
30
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)
wait(A)
T2
(ts =20)
wait(A)
T3
wait(A)
(ts =10)
ICS214B
Notes 06
31
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)
wait(A)
wait(A)
T2
(ts =20)
wait(A)
T3
(ts =10)
ICS214B
Notes 06
32
• Why do the timestamp-based schemes prevent
deadlocks?
• Reasons: for both schemes, xacts are “ordered”
and cycles are prevented in the wait-for graph
ICS214B
Notes 06
33
Next Topics:
• Long transactions (nested, compensation)
ICS214B
Notes 06
34
User/Program commands
Lots of variations, but in general
• Begin_work
• Commit_work
• Abort_work
ICS214B
Notes 06
35
Nested transactions
...
User program:
... ...
Begin_work;
If results_ok, then commit work
else abort_work
ICS214B
Notes 06
36
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
ICS214B
Notes 06
37
Parallel Nested Transactions
...
begin-work
parallel:
T11: begin_work
T1
...
T1
commit_work
T11
T12
...
T12: begin_work
...
T1:
commit_work
commit_work
ICS214B
Notes 06
38
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.
ICS214B
Notes 06
39