ICS 214B: Transaction Processing and Distributed Data Management

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

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

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

5

• Note in transactions, reads and writes
  precede commit or abort
• ? If Ci ? Ti, then ri(A) lt Ci
• wi(A) lt Ci
• ? If Ai ? Ti, then ri(A) lt Ai
• wi(A) lt Ai
• Also, only one of Ci, Ai can appear in a
  transaction

6
Back to example Tj Ti
Wj(A) ri(A) Ci ? can we commit
here? No, since Ti reads from Tj, which may abort.
...
...
...
...
7
Definition read from

• Ti reads from Tj in S (Tj ?S Ti) if
• (1) wj(A) ltS ri(A)
• (2) Aj ltS ri(A) (lt does not precede)
• (3) If wj(A) ltS wk(A) ltS ri(A) then
• Ak ltS ri(A)

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 ltS Ci

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

10

• Question How to achieve recoverable
  schedules?

11
With 2PL, hold write locks to commit (strict
2PL)

• Tj Ti
• Wj(A)
• Cj
• uj(A)
• ri(A)

...
...
...
...
...
...
...
12
With validation, no change!
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.

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

15

• Containment

SERIALIZABLE
RC
Avoids cascading rollback
ST
SERIAL
ACR
16
Next topic Deadlocks

• Easy detection timeout
• Wait-for graphs
• Prevention Resource ordering
• Detection by timestamps
• Wait-die
• Wound-wait

17
Detection Timeout

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

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
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
20
Prevention Resource Ordering

• Order all elements A1, A2, , An
• Transaction T can lock Ai after Aj only if i gt j

Problem Ordered lock requests not realistic in
most cases
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)lt ts(Tj),
• Otherwise, Ti needs to die (i.e., is rolled
  back)
• Wound-wait
• Younger xacts wait for older xacts

22
Wait-Die Example

• T1
• (ts 10)
• T2
• (ts 20)
• T3
• (ts 25)

wait
wait
23
Second Example

• T1
• (ts 22)
• T2
• (ts 20)
• T3
• (ts 25)

requests A wait for T2 or T3?
Note ts between 20 and 25.
wait(A)
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)
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)
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
27
Wound-wait scheme

• Younger xacts wait for older xacts
• Ti can wait for Tj if ts(Ti) gt 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

28
Example

• T1
• (ts 25)
• T2
• (ts 20)
• T3
• (ts 10)

wait
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

29
Second Example

• T1
• (ts 15)
• T2
• (ts 20)
• T3
• (ts 10)

requests A wait for T2 or T3?
Note ts between 10 and 20.
wait(A)
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)
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)
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)
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

34

• Next Topics
• Long transactions (nested, compensation)

35
User/Program commands

• Lots of variations, but in general
• Begin_work
• Commit_work
• Abort_work

36
Nested transactions

• User program
• Begin_work
• If results_ok, then commit work
• else abort_work

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

...
...
...
38
Parallel Nested Transactions
T1 begin-work parallel T11 begin_work comm
it_work T12 begin_work commit_work commit_wor
k
...
...
...
...
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 B1B2Bn 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
• B1B2Bn
• A B1B2Bn A-1
• Not all transactions are compensatable.