Starvation or Livelock is the situation when a transaction has to wait for a indefinite period of time to acquire a lock.
Reasons of Starvation –
- If waiting scheme for locked items is unfair. ( priority queue )
- Victim selection. ( same transaction is selected as a victim repeatedly )
- Resource leak.
- Via denial-of-service attack.
Starvation can be best explained with the help of an example – Suppose there are 3 transactions namely T1, T2, and T3 in a database that are trying to acquire a lock on data item ‘ I ‘. Now, suppose the scheduler grants the lock to T1(maybe due to some priority), and the other two transactions are waiting for the lock. As soon as the execution of T1 is over, another transaction T4 also come over and request unlock on data item I. Now, this time the scheduler grants lock to T4, and T2, T3 has to wait again. In this way if new transactions keep on requesting the lock, T2 and T3 may have to wait for an indefinite period of time, which leads to Starvation.
What are the solutions to starvation –
- Increasing Priority –
Starvation occurs when a transaction has to wait for an indefinite time, In this situation, we can increase the priority of that particular transaction/s. But the drawback with this solution is that it may happen that the other transaction may have to wait longer until the highest priority transaction comes and proceeds.
- Modification in Victim Selection algorithm –
If a transaction has been a victim of repeated selections, then the algorithm can be modified by lowering its priority over other transactions.
- First Come First Serve approach –
A fair scheduling approach i.e FCFS can be adopted, In which the transaction can acquire a lock on an item in the order, in which the requested the lock.
- Wait die and wound wait scheme –
These are the schemes that use the timestamp ordering mechanism of transaction.
For detailed study refer : Wait die and Wound wait scheme