What is the difference between "wait-die" and "wound-wait" deadlock prevention algorithms?

What is the difference between wait-die and wound-wait algorithms?

It seems that both of these deadlock prevention techniques are doing the same thing: A Rollback of older process.

What is the difference between the two?

Please provide a suitable example to contrast the two algorithms.

In both cases Old is always champ i.e. will survive. Difference is from younger transaction point of view.

If younger one is requesting a resource held by a old trans. , in wait/die he can wait to give respect as Old trans.If younger one is requesting a resource held by a old trans., in wound/die he will be force to rollback as Old trans.

In both scheme old is never in loss.

Refer:https://www.tutorialspoint.com/dbms/dbms_deadlock.htm

**wait-die**: When an **older** transaction tries to lock a DB element that has been locked by a **younger** transaction, it **waits**. When a **younger** transaction tries to lock a DB element that has been locked by an **older** transaction, it **dies**.

**wound-wait**: When an **older** transaction tries to lock a DB element that has been locked by a **younger** transaction, it **wounds** the younger transaction. When a **younger** transaction tries to lock a DB element that has been locked by an **older** transaction, it **waits**.

---
References:

- [Preventing deadlock with timestamps: the wait-die method](

[To see links please register here]

)
- [Preventing deadlock with timestamps: wound-wait scheme](

[To see links please register here]

)
- [Comparing the wait-die and wound-wait schemes](

[To see links please register here]

)

The best way to understand two related topics can be achieved by comparison. So,
Similarity between wait-die and wound-wait:

1. The older transaction will "win" over the newer transaction.
2. When transactions restart, they keep their timestamps.
3. Eventually, the aborted (younger) transactions will become the oldest transactions in the system.

Difference between wait-die and wound wait:

1. In wait-die, The newer transactions are killed when the newer transaction makes a request for a lock being held by an older transactions.
2. In wound-wait, The newer transactions are killed when an older transaction makes a request for a lock being held by the newer transactions.

I'll put the @JingguoYao's summary a bit differently.
I just rearranged it because for me (and others like me) it reads easier like this.


Assume that T<sub>n</sub> requests a lock held by T<sub>k</sub>. The following table summarizes the actions taken for wait-die and wound-wait scheme:

Tn is older than Tk Tn is younger than Tk
wait-die Tn waits Tn dies
wound-wait Tk aborts Tn waits

Both schemes prefer older transactions with an older timestamp.

Wait-Die scheme
===============
It is a **non-preemptive** technique for deadlock prevention.
When transaction T<sub>n</sub> requests a data item currently held by T<sub>k</sub>,
T<sub>n</sub> is allowed to wait only if it has a timestamp smaller than that of T<sub>k</sub>
(That is T<sub>n</sub> is *older* than T<sub>k</sub>), otherwise T<sub>n</sub> is killed ("die").

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. **Timestamp(T<sub>n</sub>) < Timestamp(T<sub>k</sub>**) −
that is T<sub>n</sub>, which is requesting a conflicting lock, is *older* than T<sub>k</sub> −
then T<sub>n</sub> is allowed to "wait" until the data-item is available.

2. **Timestamp(T<sub>n</sub>) > Timestamp(T<sub>k</sub>)** −
that is T<sub>n</sub> is *younger* than T<sub>k</sub> −
then T<sub>n</sub> is killed ("dies").
*T<sub>n</sub> is restarted later with a random delay but with the same timestamp(n).*

This scheme allows the older transaction to "wait" but kills the younger one ("die").

<h3>Example</h3>

Suppose that transaction T<sub>5</sub>, T<sub>10</sub>, T<sub>15</sub> have time-stamps 5, 10 and 15 respectively.

If T<sub>5</sub> requests a data item held by T<sub>10</sub> then T<sub>5</sub> will "wait".

If T<sub>15</sub> requests a data item held by T<sub>10</sub>, then T<sub>15</sub> will be killed ("die").


Wound-Wait scheme
=================
It is a **preemptive** technique for deadlock prevention.
It is a counterpart to the wait-die scheme.
When Transaction T<sub>n</sub> requests a data item currently held by T<sub>k</sub>,
T<sub>n</sub> is allowed to wait only if it has a timestamp larger than that of T<sub>k</sub>,
otherwise T<sub>k</sub> is killed
(i.e. T<sub>k</sub> is wounded by T<sub>n</sub>).

In this scheme, if a transaction requests to lock a resource (data item),
which is already held with conflicting lock by some another transaction, one of the two possibilities may occur:

1. **Timestamp(T<sub>n</sub>) < Timestamp(T<sub>k</sub>)**,
then T<sub>n</sub> forces T<sub>k</sub> to be killed − that is T<sub>n</sub> "wounds" T<sub>k</sub>.
*T<sub>k</sub> is restarted later with a random delay but with the same timestamp(k).*

2. **Timestamp(T<sub>n</sub>) > Timestamp(T<sub>k</sub>)**,
then T<sub>n</sub> is forced to "wait" until the resource is available.

This scheme allows the younger transaction requesting a lock to "wait" if the older transaction already holds a lock, but forces the younger one to be suspended ("wound") if the older transaction requests a lock on an item already held by the younger one.



<h3>Example</h3>

Again, suppose that Transactions T<sub>5</sub>, T<sub>10</sub>, T<sub>15</sub> have time-stamps 5, 10 and 15 respectively.

If T<sub>5</sub> requests a data item held by T<sub>10</sub>,
then data item will be preempted from T<sub>10</sub> and T<sub>10</sub> will be suspended. ("wounded")

If T<sub>15</sub> requests a data item held by T<sub>10</sub>, then T<sub>15</sub> will "wait".

Summary
-------

In both the cases, only the transaction that enters the system at a *later* timestamp (i.e. the younger transaction) might be killed and restarted.

Parth has given a detailed answer. Here I summarize it in a different way.

Assume that T<sub>n</sub> requests a lock held by T<sub>k</sub>. The following table summarizes the actions taken for wait-die and wound-wait scheme:

wait-die wound-wait
Tn is younger than Tk Tn dies Tn waits
Tn is older than Tk Tn waits Tk aborts


Both schemes prefer older transactions with an older timestamp.

[![Deadlock prevention][1]][1]


[1]:

- A deadlock is created when both edges form, as shown in the graph
above. A young transaction requests a lock from an old transaction, and an
old transaction requests a lock from a young transaction.
- Each of the 2 techniques just prevents one of the edges from being
formed while allowing the other edge, hence preemptively preventing a
cycle from being formed.
- If you notice, in both strategies, the young transaction gets
aborted. Only the initiator of the lock request differs. Aborted
transactions are restarted at a later point in time.