Starvation in DBMS

When a transaction must wait an endless amount of time to obtain a lock, this is known as starvation or livelock.

Reasons for Starvation:

• If the waiting system for locked things is unjust, people may starve. (A priority line)
• Selecting victims (the same transaction is selected as a victim repeatedly )
• Leak of resources.
• Through a denial-of-service assault.

The greatest way to illustrate starvation is with the aid of an example:

Assume that three transactions, T1, T2, and T3, are vying for a lock on the data item "I" in a database. Now imagine that T1 receives the lock from the scheduler (perhaps as a result of a priority), while the other two transactions are still awaiting the lock. As soon as transaction T1 has finished running, transaction T4 joins in and asks for a lock on data item I. Now that T4 has been granted lock, T2, T3, and the scheduler must wait once again. T2 and T3 may experience starvation if other transactions continuously seeking the lock and forcing T2 and T3 to wait for an extended amount of time.

Preventing starvation:

• Solutions to the problem of starvation: A transaction enters starvation when it must wait for an endless period of time. In this case, we can raise the priority of the relevant transaction or transactions. The disadvantage of this approach is that it could be necessary for the other transaction to wait longer before the highest priority transaction arrives and is completed.
• Victim Selection Algorithm Modification: If a transaction has experienced many selections, the algorithm can be changed by reducing its priority relative to other transactions.
• Approach of first come, first served: The transaction can gain a lock on an item in the order in which the requested lock is acquired using a fair scheduling technique, or FCFS.
• Wounded wait and wait-die strategies: These are the methods that employ the transaction ordering system based on timestamps.

Starvation in a database management system (DBMS) is when a transaction or process is repeatedly delayed or stalled because it cannot access the resources it needs to move forward. When other transactions or processes take precedence over the one that is starving, this might occur.

Resources like locks, memory, and CPU time are frequently shared by several transactions or processes in DBMSs. A starving situation involving one or more transactions or processes is conceivable if some transactions or processes are given precedence over others.

For instance, if one transaction is waiting for a lock that another transaction is holding, if the second transaction never releases the lock, the first transaction may be stalled indefinitely. If the initial transaction is consistently stalled and unable to go forward, this may cause starvation to occur.

DBMSs often employ a variety of strategies to stop or lessen famine, including:

• Policies for resource allocation can be used by DBMSs to distribute resources fairly, making sure that no transaction or process is routinely given priority over others.
• DBMSs can utilize scheduling algorithms that take the priority of transactions or processes into consideration, guaranteeing that high-priority transactions or processes are completed before low-priority ones. This is known as priority-based scheduling.
• Timeout methods: By releasing resources if a transaction or process waits for too long, DBMSs can utilize timeout mechanisms to stop transactions or processes from being stalled forever.
• Resource management: To prevent any one transaction or process from monopolizing resources and preventing famine, DBMSs can also employ strategies like resource quotas and restrictions.

A data base management system is a piece of system software for the quick, dependable, and easy processing of data. It is suitable for:

• Building a database.
• Information retrieval from the database.
• The database being updated.
• Taking care of a database.

It offers us a variety of features and has some advantages over the conventional file system, as follows:

1) Processing Queries and Object Management: In traditional file systems, we cannot store data in the form of objects. Applications used in the real world save data as objects rather than files. So that it may be utilized further, some application software in a file system translates the data saved in files to objects.

With a database management system, we may directly store data as objects. A file system requires application level code to manage, store, and browse the data, but a database management system (DBMS) allows us to query the database.

2) Managing redundancy and consistency: Redundancy is the practice of using the same data again. While the same data may be saved more than once in a file system, a database system offers redundancy management. For example, if a student is studying two distinct educational programmers at the same institution, say ,Engineering and History, then his information such as the phone number and address may be recorded several times, one in Engineering dept and the other in History dept. As a result, it lengthens the time needed to access and store data. Moreover, this might result in disparate data states in both locations. To prevent duplication and redundancy, DBMSs utilize data normalization.

3) Efficient memory management and indexing: DBMS makes sophisticated memory management easier to handle. With file systems, files are indexed in place of objects therefore query operations need whole file scans whereas in a DBMS, object indexing takes place rapidly using database design based on any attribute of the data or a data-property. This assists in rapid retrieval of data depending on the indexed property.

4) Transaction management and concurrency control: A number of apps provide simultaneous data access. As a result, there can be inconsistent data when case files are used. Take into consideration two withdrawal transactions X and Y wherein 100 and 200 are withdrew from an account A that had a starting balance of 1000. When numerous transactions are occurring simultaneously, the account may be updated in a variety of ways by various transactions. X reads 1000, debits 100, updates the account A to 900, whereas Y likewise reads 1000, debits 200, updates A to 800. In both circumstances account A has inaccurate information. As a result, the data are inconsistent. A DBMS provides ways to cope with this form of data inconsistency while allowing users to access data simultaneously.

5) Access Control and simplicity in obtaining data: A DBMS may provide access to multiple users and select which part and how much of the data can they access from the database thus eliminating redundancy. If not, the file system requires that separate files detailing the quantity of data that each user may access be generated for each user. Additionally, if a user wants to extract certain data, then he requires a code/application to accomplish that task in case of file system, e.g. Say a manager desires a list of all workers with salaries more than X. If data is saved in files, we then need to build business logic for the same.