Database-Management-System
August 29, 2024Database-Management-System
August 29, 2024Transactions
| Question 62 |
When transaction T i requests a data item currently held by T j , T j is allowed to wait only if it has a timestamp smaller than that of T j (that is, T i older than T j ). Otherwise, T i is rolled back(dies). this is
| Wait-die | |
| Wait-wound | |
| Wound-Wait | |
| Wait |
Question 62 Explanation:
Wait-die scheme :
It is a non-preemptive technique for deadlock prevention. When transaction T i requests a data item currently held by T j , T i is allowed to wait only if it has a timestamp smaller than that of
T j (That is T i is older than T j ), otherwise T i is rolled back (dies).
→ In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur
1. If TS(T i ) < TS(T j ) − that is T i , which is requesting a conflicting lock, is older than T j −then Ti is allowed to wait until the data-item is available.
2. If TS(T i ) > TS(T j ) − that is T i is younger than T j − then T i dies. T i is restarted later with a random delay but with the same timestamp.
→ This scheme allows the older transaction to wait but kills the younger one.
Example:
Suppose that transaction T22, T23, T24 have time-stamps 5, 10 and 15 respectively. If T22 requests a data item held by T23 then T22 will wait. If T24 requests a data item held by T23, then T24 will be rolled back.
It is a non-preemptive technique for deadlock prevention. When transaction T i requests a data item currently held by T j , T i is allowed to wait only if it has a timestamp smaller than that of
T j (That is T i is older than T j ), otherwise T i is rolled back (dies).
→ In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur
1. If TS(T i ) < TS(T j ) − that is T i , which is requesting a conflicting lock, is older than T j −then Ti is allowed to wait until the data-item is available.
2. If TS(T i ) > TS(T j ) − that is T i is younger than T j − then T i dies. T i is restarted later with a random delay but with the same timestamp.
→ This scheme allows the older transaction to wait but kills the younger one.
Example:
Suppose that transaction T22, T23, T24 have time-stamps 5, 10 and 15 respectively. If T22 requests a data item held by T23 then T22 will wait. If T24 requests a data item held by T23, then T24 will be rolled back.
Correct Answer: A
Question 62 Explanation:
Wait-die scheme :
It is a non-preemptive technique for deadlock prevention. When transaction T i requests a data item currently held by T j , T i is allowed to wait only if it has a timestamp smaller than that of
T j (That is T i is older than T j ), otherwise T i is rolled back (dies).
→ In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur
1. If TS(T i ) < TS(T j ) − that is T i , which is requesting a conflicting lock, is older than T j −then Ti is allowed to wait until the data-item is available.
2. If TS(T i ) > TS(T j ) − that is T i is younger than T j − then T i dies. T i is restarted later with a random delay but with the same timestamp.
→ This scheme allows the older transaction to wait but kills the younger one.
Example:
Suppose that transaction T22, T23, T24 have time-stamps 5, 10 and 15 respectively. If T22 requests a data item held by T23 then T22 will wait. If T24 requests a data item held by T23, then T24 will be rolled back.
It is a non-preemptive technique for deadlock prevention. When transaction T i requests a data item currently held by T j , T i is allowed to wait only if it has a timestamp smaller than that of
T j (That is T i is older than T j ), otherwise T i is rolled back (dies).
→ In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur
1. If TS(T i ) < TS(T j ) − that is T i , which is requesting a conflicting lock, is older than T j −then Ti is allowed to wait until the data-item is available.
2. If TS(T i ) > TS(T j ) − that is T i is younger than T j − then T i dies. T i is restarted later with a random delay but with the same timestamp.
→ This scheme allows the older transaction to wait but kills the younger one.
Example:
Suppose that transaction T22, T23, T24 have time-stamps 5, 10 and 15 respectively. If T22 requests a data item held by T23 then T22 will wait. If T24 requests a data item held by T23, then T24 will be rolled back.