Scribd
Upload
28 views5 pages

CS 3306 01 Written Assignment Unit 2

Provides answers to unit 2 written assignment.

Uploaded by

Nel Matrix
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
28 views5 pages

CS 3306 01 Written Assignment Unit 2

Provides answers to unit 2 written assignment.

Uploaded by

Nel Matrix
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Written Assignment Unit 2

University of the People

Department of Computer Science

CS 3306-01 - DATABASE 2 - AY2025-T2

Dr. Brian Stevens (Instructor)

November 21st, 2024


Deadlock Recovery: Actions for Breaking Deadlocked Transactions in Database

Systems

When a detection algorithm determines that a deadlock exists, the system must recover from the

deadlock. The most common solution is to roll back one or more transactions to break the

deadlock. List the three actions that need to be taken using Figure 16.19 to discuss.

Figure 16.19, as depicted in the textbook, is provided below:

From the wait-for graph above, we can observe that the system comprises four transactions: T25, T26,

T27, and T28. T26, T27, and T28 are deadlocked transactions because they form a cyclic connection

within the graph.

According to Silberschatz et Al (2001), to resolve a transaction deadlock in a database, some or all of the

deadlocked transactions must be rolled back, partially or totally. This process involves three essential

actions that need to be taken, which are:

Selection of victim

Rollback

Starvation

Each action is discussed below, using the wait-for graph as a reference.


Selection of Victim

To resolve a deadlock, the system must identify and terminate (or roll back) one or more transactions to

break the cyclic dependency. The aim of this action is to choose a victim that incurs the least cost upon

rollback. We do so based on the following criteria, as elaborated by Silberschatz et Al (2001):

The duration the transaction has been running and the estimated time remaining to complete its task.

The number of data items the transaction has already accessed.

The additional data items are required for the transaction to finish.

The number of transactions that will be affected by the rollback.

To break the cycle illustrated in Figure 16.19, the system identifies that T26 is holding resources needed

by T27, T27 is holding resources required by T28, and T28 is waiting for resources held by T26. The

system then evaluates the rollback cost for each transaction. If T28 has the lowest rollback cost, it will

be chosen as the victim and terminated. Rolling back T28 breaks the cycle, allowing the remaining

transactions to proceed.

Rollback

After selecting a victim transaction, such as T28 from the wait-for graph in Figure 16.19, the next step is

to roll back the transaction to release the resources it holds, effectively breaking the deadlock cycle.

Rolling back involves undoing all or part of the transaction to restore the system to a consistent state. As

elaborated by Silberschatz et Al (2001), there are two main types of rollbacks that can be performed:

Partial Rollback:

Instead of aborting the entire transaction, only part of its operations is undone. The transaction is rolled
back to a specific point where the deadlock can be resolved, after which it is restarted or continues from

that point.

Total Rollback:

The transaction is fully aborted, and all of its changes to the database are undone. This ensures that all

resources held by the transaction are released, allowing other transactions to proceed.

This means that In the wait-for graph if T28 is selected as the victim, it can either be completely rolled

back (terminated) or partially rolled back to a point where it no longer holds the resources required by

T26. By releasing the resources held by T28, T26 and T27 can resume their execution, effectively

breaking the deadlock cycle.

Starvation

Starvation happens when a transaction is repeatedly chosen as a victim and rolled back during deadlock

resolution, preventing it from ever completing its execution (Silberschatz et Al., 2001). To avoid

starvation, the system must guarantee that every transaction eventually makes progress and is completed

(Silberschatz et Al., 2001). This can be achieved by implementing strategies that ensure fairness in

victim selection.

In the given wait-for graph, if T28 is continuously selected as the victim due to its lowest rollback cost,

it may never finish its execution, leading to starvation. To prevent this, the system must implement

mechanisms to ensure that T28 is eventually allowed to complete.


In conclusion, these are the three actions that are taken when a system comes across deadlocks and

needs to take care of them using deadlock detection algorithms and deadlock recovery mechanisms.

Reference:

Silberschatz, A., Korth, H.F., & Sudarshan, S. (2001). Database System Concepts (4th ed.). New York,

NY: McGraw-Hill. Available at Database System Concepts 4th Edition By Silberschatz-Korth-

Sudarshan.pdf)

You might also like