Scribd Logo
Upload

Welcome to Scribd!

  • Transactions Given A Timestamp When They Arrive . Ts (T) T Can Only Wait For T If Ts (T) Ts (T) ... Else Die T T T

    Uploaded by

    Sweta Shaw
    10 views11 pages
    The document discusses different strategies for handling transaction conflicts in a database system with timestamps. It compares a "wait-die" approach, where a transaction will wait for any conflicting older transactions and die if a newer one arrives, against a "wound-wait" approach, where a transaction will either wait for or wound (rollback) any older conflicting transactions. Several options are considered for how a transaction might handle waiting for or wounding multiple other transactions in different situations. Managing these approaches requires addressing issues like transaction starvation, unnecessary rollbacks, and revising the wait-for graph.

    Original Description:

    deadlock complete description.easily understandable.

    Original Title

    Deadlocks

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PPT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    The document discusses different strategies for handling transaction conflicts in a database system with timestamps. It compares a "wait-die" approach, where a transaction will wait for any conflicting older transactions and die if a newer one arrives, against a "wound-wait" approach, where a transaction will either wait for or wound (rollback) any older conflicting transactions. Several options are considered for how a transaction might handle waiting for or wounding multiple other transactions in different situations. Managing these approaches requires addressing issues like transaction starvation, unnecessary rollbacks, and revising the wait-for graph.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Flag for inappropriate content
    10 views11 pages

    Transactions Given A Timestamp When They Arrive . Ts (T) T Can Only Wait For T If Ts (T) Ts (T) ... Else Die T T T

    Uploaded by

    Sweta Shaw
    The document discusses different strategies for handling transaction conflicts in a database system with timestamps. It compares a "wait-die" approach, where a transaction will wait for any conflicting older transactions and die if a newer one arrives, against a "wound-wait" approach, where a transaction will either wait for or wound (rollback) any older conflicting transactions. Several options are considered for how a transaction might handle waiting for or wounding multiple other transactions in different situations. Managing these approaches requires addressing issues like transaction starvation, unnecessary rollbacks, and revising the wait-for graph.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Flag for inappropriate content
    of 11

    Wait-die

    Transactions given a timestamp when they arrive . ts(Ti) Ti can only wait for Tj if ts(Ti)< ts(Tj) ...else die T1 Wait for A
    (ts =10)

    T2
    Wait for C? (ts =20)

    T3

    Wait fo B

    (ts =25)

    Wait-die-1
    T1
    (ts =22)
    Note: ts between 20 and 25.

    requests A: wait for T2 or T3 or both? (in my html notes, I assume both)

    T2
    wait(A)

    (ts =20)

    T3
    (ts =25)

    Wait-die-1
    One option: T1 waits just for T3, transaction holding lock.
    But when T2 gets lock, T1 will have to die! (also lots of WFG revision)

    T1
    (ts =22)
    wait(A)

    T2
    wait(A)

    wait(A)

    (ts =20)

    T3
    (ts =25)

    Wait-die-2

    Another option: T1 waits for both T2, T3 E.g., (saves having to revise WFG) T1 allowed to wait iff there is at least one younger trans wait-involved with A. But again, when T2 gets lock, T1 must die!

    T1
    (ts =22)
    wait(A) wait(A)

    wait(A)

    T2
    (ts =20)

    T3
    (ts =25)

    Wait-die-3
    Yet another option: T1 preempts T2 (T2 is just waiting idly anyway), so T1 only waits for T3; T2 then waits for T3 But, T2 may starve? And lots of WFG work for Deadlock Mgr (shifting edges)

    (ts =22)

    T1
    wait-A

    wait(A)

    (ts =20)

    T2

    (ts =25)

    T3

    Wound-wait

    Transactions given a timestamp when they arrive ts(Ti) Ti wounds Tj if ts(Ti)< ts(Tj) else Ti waits

    Wound: Tj rolls back (if it cannot finish in small interval of time) and gives lock to Ti

    Wound-wait
    T1
    (ts =25) Wait C
    Wait A

    T2
    Wait B

    (ts =20)

    T3
    (ts =10)

    Wound-wait-2
    T1
    (ts =15)
    Note: ts between 10 and 20.

    requests A: wait for T2 or T3?

    T2
    wait(A)

    (ts =20)

    T3
    (ts =10)

    Wound-wait-2
    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)
    wait(A) wait(A)
    Wait A

    T2
    (ts =20)

    T3
    (ts =10)

    Wound-wait-3
    Another option: T1 waits for both T2, T3

    T2 wounded right away!

    T1
    (ts =15)
    wait(A) wait(A)

    wait(A)

    T2
    (ts =20)

    T3
    (ts =10)

    Wound-wait-4
    Yet another option: T1 preempts T2, so T1 only waits for T3; T2 then waits for T3 and T1... T2 is spared! Lots
    of WFG work for Deadlock Mgr (shifting edges) and T2 may starve.

    T1
    (ts =15)
    wait(A) wait-A

    T2
    (ts =20)

    T3
    (ts =10)

    You might also like