Code360 powered by Coding Ninjas X Code360 powered by Coding Ninjas X
Table of contents
What is Starvation?
Reasons for Starvation
Solutions to Starvation
Preventing Starvation in DBMS
Disadvantages of Starvation in DBMS
Frequently Asked Questions
What is the most probable scheduling level where starvation could happen?
Is it possible for a system to identify when some of its processes are starving?
Last Updated: Jul 4, 2024

Starvation in DBMS

Author Divyansh Jain
1 upvote
Master Python: Predicting weather forecasts
Ashwin Goyal
Product Manager @


In the bustling world of databases, where data flows freely and transactions are the lifeblood, a hidden threat can lurk: starvation. It's not a lack of data itself, but a scenario where transactions are unfairly denied the resources they need to proceed. This blog post delves into the complexities of starvation in Database Management Systems (DBMS), exploring its causes, consequences, and potential solutions.

Starvation in DBMS

What is Starvation?

Starvation in DBMS refers to a situation where a transaction or process is continuously denied the essential resources it needs to progress or even finish its execution. Imagine a long queue at a restaurant, but some customers never get served, their orders perpetually on hold. That's akin to what happens in a DBMS with starvation.


Let’s try to understand starvation with a brief example,

Assume there are three transactions in a database as A, B, and C, all attempting to obtain a lock on the data item 'X '. Assume the scheduler gives the lock to A (perhaps owing to a priority), and the other two operations are waiting for it. As soon as process A completes its execution, another process D arrives and demands a lock on data item X. This time, the scheduler provides the lock to D, and B, C must wait once again. If additional operations continue to request the lock, B and C may be forced to wait for an endless amount of time, resulting in Starvation.

Regardless of how it occurs, starving is clearly a negative thing. More technically, it's bad because we don't want a non-functional system. 




Note: If a system is vulnerable to starvation, a process that enters the system may be delayed for an indefinite period of time. 

In order to avoid starvation, we commonly say that we want the system's resources to be divided "fairly" to avoid starvation. This is a nice idea, but it's useless in reality since it doesn't specify what "fairly" means, thus it's more of a description of the problem than a contribution to its solution. It's more productive to look at the pathways that a system can take to become livelocked and try to manage them.

You can also read about the Multiple Granularity Locking, Multiple Granularity in DBMS

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job

Reasons for Starvation

Starvation in a DBMS can arise from various factors that lead to a transaction being unfairly denied resources for an extended period.

  • Prioritization of processes is carefully enforced. If a process with a lower priority demands a resource and is competing with a steady stream of processes with a higher priority, it may have to wait indefinitely.
  • Starvation can be seen when the strategy for locked items is inappropriate. (like a priority queue).
  • Processes uncontrollably transfer resources to other processes. Discrepancies can develop if resource allocation choices are made locally without addressing the system's overall resource requirements. If processes queue for a resource and the resource is always passed on to the next process in the queue, every process that needs the resource must be added to the queue.
  • Choosing a victim (the single transaction is considered as a victim again and again).
  • A similar condition can also be seen when there is a leakage of resources.
  • It should be feasible to meet demand if resource availability exceeds the need for a fair amount of time, and methods may be adopted to offer service to all processes that want it. On the other hand, if demand exceeds supply, no amount of clever deception will be able to satisfy everyone, and starvation is a real possibility.
  • It can occur as a result of a denial-of-service attack.
  • When a "random" selection method is employed. If processes that are waiting for service are not queued and instead a random process is chosen once the resource becomes available, some processes may have to wait for a lengthy period.


Recommended Topic, B+ Tree in DBMS  and  Checkpoint in DBMS

Solutions to Starvation

In general, cures for starvation are predicated on preventing the factors that lead to starvation. Let’s have a glimpse of it.

  • A fair scheduling strategy, referred to as FCFS( First Come First Serve ), can be used, in which the transaction can obtain a lock on an item in the order in which the lock was requested.
  • By Increasing the Priority: When a transaction must wait for an infinite period of time, it is possible to raise the priority of that process. However, the disadvantage of this technique is that subsequent transactions may have to wait longer until the highest priority process arrives and is processed.
  • Using Victim Selection Algorithm Modification: If a transaction has been selected several times, the algorithm can be tweaked by decreasing its priority over other transactions.
  • The wait-die and wound-wait method can also be used, it refers to the transaction ordering techniques that leverage the timestamp ordering mechanism.
  • Each resource must have its own independent manager who is responsible for all allocations of that resource. This will ensure that processes do not just pass resources between themselves without making them accessible for general allocation.
  • More resources are needed. When demand exceeds supply, this is the only viable option for continuous congestion. Even modest swings in demand can cause lineups to build, which can take a long time to clear if supply and demand are tightly balanced. Of course, if you have enough resources to keep queues to a bare minimum in any reasonable demand situation, you will have moments when the resource is idle.

You can also read about the Log based recovery and Recursive Relationship in DBMS.

Preventing Starvation in DBMS

Starvation is a serious issue in DBMS, but thankfully, there are techniques to prevent it and ensure fair resource allocation:

  • Fair Scheduling Algorithms: Implementing algorithms like First-Come-First-Served (FCFS) or Priority-based scheduling ensures transactions are processed in a predictable order. This prevents older or smaller transactions from indefinitely blocking newer ones.
  • Resource Management: Techniques like timeouts and quotas can be used. Timeouts automatically release resources held by a transaction for too long, preventing others from starving. Quotas limit the amount of resources a single transaction can consume, ensuring fairer distribution.
  • Deadlock Prevention: Careful database design and deadlock detection algorithms can help avoid situations where transactions become locked in a wait-die loop. This prevents deadlocks and the resulting starvation.
  • Transaction Monitoring: Monitoring transaction performance and resource usage can help identify potential starvation scenarios. This allows administrators to adjust resource allocation or optimize transaction logic if necessary.
  • Priority Levels: Assigning appropriate priority levels to transactions ensures critical operations are not delayed by less important ones. This helps maintain system stability and responsiveness.

These strategies work together to create a more balanced and efficient database environment, minimizing the risk of transaction starvation.

Disadvantages of Starvation in DBMS

Starvation can have a significant negative impact on the overall performance and functionality of a DBMS:

  • Reduced Performance: Transactions waiting indefinitely for resources block others, creating a chain reaction that slows down the entire system. Users might experience sluggish response times and delays in operations.
  • Unresponsive Database: In severe cases, a starved system might become unresponsive or even crash. This can lead to data loss or service outages, hindering user productivity and potentially causing business disruptions.
  • Data Integrity Issues: When transactions starve and fail to complete due to resource denial, data consistency can be compromised. This can lead to inaccurate or incomplete data, affecting the reliability and trustworthiness of the database.
  • Unpredictable Behavior: Starvation creates an unpredictable environment. It becomes difficult to estimate transaction completion times and ensure consistent performance, hindering system reliability.

Frequently Asked Questions

What is the most probable scheduling level where starvation could happen?

Starvation can occur at any level of organized scheduling, however, it is more common in automatic allocation procedures than in higher-level manual sections. (We presume that at the manual level, there is more intelligence and flexibility; bureaucracy may contradict this assumption.)

Is it possible for a system to identify when some of its processes are starving?

Starvation detection necessitates future knowledge since no amount of process statistics can identify whether it is making 'progress' or not. This process keeps a rollback count for each process and factoring it into the cost considerations when choosing a victim for preemption/rollback.


To summarize the article, we learned the concept of Starvation in DBMS. The world of DBMS can be a demanding one, with transactions constantly vying for resources. Starvation, where transactions are denied essential resources for extended periods, can lead to a system on the brink of collapse. Understanding its causes and implementing preventive measures is crucial for maintaining a healthy database environment.

Recommended topics:

Happy learning :)

Previous article
Log Based recovery in DBMS
Next article
Introduction to File Organization
Live masterclass