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

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.
Example
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.
Source:meme-arsenal
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