Open In App

Starvation in DBMS

Improve
Improve
Improve
Like Article
Like
Save Article
Save
Share
Report issue
Report

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.

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 is 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 comes over and requests a 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 to starvation:

  1. 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.
  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 lock.
  4. Wait-die and wound wait scheme: These are the schemes that use the timestamp ordering mechanism of transactions. 
  5. Timeout Mechanism: A timeout mechanism can be implemented in which a transaction is only allowed to wait for a certain amount of time before it is aborted or restarted. This ensures that no transaction waits indefinitely, and prevents the possibility of starvation.
  6. Resource Reservation: A resource reservation scheme can be used to allocate resources to a transaction before it starts execution. This ensures that the transaction has access to the necessary resources and reduces the chances of waiting for a resource indefinitely.
  7. Preemption: Preemption involves the forcible removal of a lock from a transaction that has been waiting for a long time, in favor of another transaction that has a higher priority or has been waiting for a shorter time. Preemption ensures that no transaction waits indefinitely, and prevents the possibility of starvation.
  8. Dynamic Lock Allocation: In this approach, locks are allocated dynamically based on the current state of the system. The system may analyze the current lock requests and allocate locks in such a way that prevents deadlocks and reduces the chances of starvation.
  9. Parallelism: By allowing multiple transactions to execute in parallel, the system can ensure that no transaction waits indefinitely, and reduces the chances of starvation. This approach requires careful consideration of the potential for conflicts and race conditions between transactions.
For detailed study refer: Wait die and Wound wait scheme

In a database management system (DBMS), starvation occurs when a transaction or process is not able to get the resources it needs to proceed and is continuously delayed or blocked. This can happen when other transactions or processes are given priority over the one that is experiencing starvation.

In DBMSs, resources such as locks, memory, and CPU time are typically shared among multiple transactions or processes. If some transactions or processes are given priority over others, it is possible for one or more transactions or processes to experience starvation.

For example, if a transaction is waiting for a lock that is held by another transaction, it may be blocked indefinitely if the other transaction never releases the lock. This can lead to the first transaction experiencing starvation if it is continuously blocked and unable to proceed.

DBMSs typically use various techniques to prevent or mitigate starvation, such as:

Resource allocation policies: DBMSs can use policies to allocate resources in a fair manner, ensuring that no transaction or process is consistently given priority over others.

Priority-based scheduling: DBMSs can use scheduling algorithms that take into account the priority of transactions or processes, ensuring that high-priority transactions or processes are executed before low-priority ones.

Timeout mechanisms: DBMSs can use timeout mechanisms to prevent transactions or processes from being blocked indefinitely, by releasing resources if a transaction or process waits for too long.

Resource management: DBMSs can also use techniques such as resource quotas and limits to prevent any single transaction or process from monopolizing resources, thus reducing the likelihood of starvation.

Disadvantages of Starvation:

Decreased performance: Starvation can cause decreased performance in a DBMS by preventing transactions from making progress and causing a bottleneck.

Increased response time: Starvation can increase response time for transactions that are waiting for resources, leading to poor user experience and decreased productivity.

Inconsistent data: If a transaction is unable to complete due to starvation, it may leave the database in an inconsistent state, which can lead to data corruption and other problems.

Difficulty in troubleshooting: Starvation can be difficult to troubleshoot because it may not be immediately apparent which transaction is causing the problem.

Potential for deadlock: If multiple transactions are competing for the same resources, starvation can lead to deadlock, where none of the transactions can proceed, causing a complete system failure.


Last Updated : 24 Apr, 2023
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads