1

ICS 214B: Transaction Processing and Distributed Data Management

Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions

Professor Chen Li

ICS214B Notes 06 2

Topics:• Cascading rollback, recoverable

schedule• Deadlocks

– Prevention– Detection

ICS214B Notes 06 3

Example: Tj Ti

Wj(A) ri(A) Commit Ti

Abort TjSchedule is • conflict serializable (Tj Ti)• but not recoverable• Cascading rollback (Bad!)

Concurrency control & recovery

……

… ……

…

ICS214B 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

ICS214B 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

ICS214B Notes 06 6

......

......

Back to example:

Tj Ti

Wj(A)ri(A)

Ci can we commit here?No, since Ti reads from Tj, which may abort.

ICS214B Notes 06 7

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 8

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

ICS214B Notes 06 10

Question: How to achieve recoverable schedules?

ICS214B Notes 06 11

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

Tj Ti

Wj(A)

Cjuj(A)

ri(A)

......

...

......

......

ICS214B Notes 06 12

With validation, no change!

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

ICS214B 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

ICS214B Notes 06 15

• Containment:

Avoids cascading rollback

RC

ACR

ST SERIAL

SERIALIZABLE

ICS214B Notes 06 16

Next topic: Deadlocks• Easy detection: timeout• Wait-for graphs• Prevention: Resource ordering• Detection by timestamps

– Wait-die– Wound-wait

ICS214B Notes 06 17

Detection: Timeout• If transaction waits more than L

sec., roll it back!

• Simple scheme• Hard to select L

ICS214B 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

T1 T2

ICS214B Notes 06 19

Deadlock Detection• Build Wait-For graph, check acyclicity• Use lock table structures• Build incrementally or periodically• When cycle found, rollback victims

T1

T3

T2

T6

T5

T4T7

ICS214B 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

ICS214B 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

ICS214B Notes 06 22

T1(ts =10)

T2(ts =20)

T3 (ts =25)

wait

wait

Wait-Die: Example

wait?

ICS214B Notes 06 23

T1(ts =22)

T2(ts =20)

T3 (ts =25)

wait(A)

Second Example

requests A: wait for T2 or T3?

Note: ts between20 and 25.

ICS214B Notes 06 24

T1(ts =22)

T2(ts =20)

T3 (ts =25)

wait(A)

Second Example (continued):

wait(A)

One option: T1 waits just for T3, transaction holding lock.But if T2 gets lock, T1 will have to die!

ICS214B Notes 06 25

T1(ts =22)

T2(ts =20)

T3 (ts =25)

wait(A)

Second Example (continued):

wait(A)

wait(A)

Another option: T1 only gets A lock after T2, T3 complete,so T1 waits for both T2, T3 T1 dies right away!

ICS214B Notes 06 26

T1(ts =22)

T2(ts =20)

T3 (ts =25)

wait(A)

Second Example (continued):

wait(A)

wait(A)

Yet another option: T1 preempts T2, so T1 only waits for T3; T2 then waits for T3 and T1... T2 may starve?

redundant arc

ICS214B 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

ICS214B Notes 06 28

T1(ts =25)

T2(ts =20)

T3 (ts =10)

wait

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

ICS214B Notes 06 29

T1(ts =15)

T2(ts =20)

T3 (ts =10)

wait(A)

Second Example:

requests A: wait for T2 or T3?

Note: ts between10 and 20.

ICS214B Notes 06 30

T1(ts =15)

T2(ts =20)

T3 (ts =10)

wait(A)

Second Example (continued):

wait(A)

One option: T1 waits just for T3, transaction holding lock.But when T2 gets lock, T1 waits for T2 and wounds T2.

ICS214B Notes 06 31

T1(ts =15)

T2(ts =20)

T3 (ts =10)

wait(A)

Second Example (continued):

wait(A)

wait(A)

Another option: T1 only gets A lock after T2, T3 complete,so T1 waits for both T2, T3 T2 wounded right away!

ICS214B Notes 06 32

T1(ts =15)

T2(ts =20)

T3 (ts =10)

wait(A)

Second Example (continued):

wait(A)

wait(A)

Yet another option: T1 preempts T2, so T1 only waits for T3; T2 then waits for T3 and T1... T2 is spared!

ICS214B 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

ICS214B Notes 06 34

Next Topics:• Long transactions (nested,

compensation)

ICS214B Notes 06 35

User/Program commandsLots of variations, but in general• Begin_work• Commit_work• Abort_work

ICS214B Notes 06 36

Nested transactionsUser program:

Begin_work;

If results_ok, then commit workelse abort_work

......

...

ICS214B Notes 06 37

Nested transactionsUser program:

Begin_work;Begin_work;

If results_ok, then commit work else {abort_work; try something else…}

If results_ok, then commit workelse abort_work

...

...

...

ICS214B Notes 06 38

Parallel Nested TransactionsT1: begin-work

parallel:T11: begin_work

commit_workT12: begin_work

commit_workcommit_work

......

......

T1

T11 T12

T1

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