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.