Starvation in DBMS

 Starvation in DBMS 

Starvation or Livelock is the situation when a transaction has to wait for an indefinite period of time to acquire a lock.

Reasons for Starvation –

· If the waiting scheme for locked items is unfair. ( priority queue )

· Victim selection. (the same transaction is selected as a victim repeatedly )

· Resource leak.

· Via denial-of-service attack.

 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 ‘.

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 to lock 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.

 Solutions of Starvation –

1. Increasing Priority –
Starvation occurs when a transaction has to wait for an indefinite time, In 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.

2. 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.

3. 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.

4. Wait for the die and wound wait scheme –
These are the schemes that use the timestamp ordering mechanism of transaction.

==================================================