Deadlock in DBMS

• The Deadlock is a condition in a multi-user database environment

where transactions are unable to the complete because they are each
waiting for the resources held by other transactions. This results in a
cycle of the dependencies where no transaction can proceed.
• In database management systems (DBMS) a deadlock occurs when
two or more transactions are unable to the proceed because each
transaction is waiting for the other to the release locks on resources.
This situation creates a cycle of the dependencies
Example of deadlock
• In the student table, transaction T1 holds a lock on some rows and
needs to update some rows in the grade table. Simultaneously,
transaction T2 holds locks on some rows in the grade table and needs
to update the rows in the Student table held by Transaction T1.

• Now, the main problem arises. Now Transaction T1 is waiting for T2 to

release its lock and similarly, transaction T2 is waiting for T1 to release
its lock. All activities come to a halt state and remain at a standstill. It
will remain in a standstill until the DBMS detects the deadlock and
aborts one of the transactions.
Deadlock Avoidance

The deadlock avoidance method is suitable for smaller databases whereas the deadlock
prevention method is suitable for larger databases.
• To avoid deadlock (where two processes are stuck waiting for each other), one way is to
make sure that all transactions (processes) follow the same order when accessing
information. For example, if two transactions need to look at both "Students" and "Grades,"
they should always access them in the same order. This way, if one transaction is already
using "Grades," the other one just waits until the first is finished, and then it can continue
without issues.
• Another way to reduce deadlocks is to use a row-level locking system (where only specific
rows are locked instead of the whole table) and an isolation level called "READ
COMMITTED" (where each transaction only sees committed changes). However, this method
doesn’t completely prevent deadlocks; it just reduces the chances of them happening.
• To avoid deadlock (where two tasks get stuck waiting for each other), one way is to
lock only the specific rows you need, not the entire table. This is called "row-level
locking."Also, using something called "READ COMMITTED" makes sure that each
task only sees changes that are finished.
• Row-Level Locking
• Imagine you have a big list of names. Instead of blocking the whole list when you
want to change just one name, you only block that one name. This is what "row-
level locking" does—locks only what you need.
• READ COMMITTED
• "READ COMMITTED" means you only see changes that are completely finished by
others. For example, if someone is still changing a name, you won’t see it until
they are done.
What is Deadlock Detection?
• When a transaction waits indefinitely to obtain a lock,
The database management system should detect
whether the transaction is involved in a deadlock or
not.
• Wait-for-graph is one of the methods for detecting the
deadlock situation. This method is suitable for smaller
databases. In this method, a graph is drawn based on
the transaction and its lock on the resource. If the graph
created has a closed loop or a cycle, then there is a
deadlock.
• For the above-mentioned scenario, the Wait-For graph is drawn
below:
What is Deadlock Prevention?
• For a large database, the deadlock prevention method is suitable. A
deadlock can be prevented if the resources are allocated in such a
way that a deadlock never occurs. The DBMS analyzes the operations
whether they can create a deadlock situation or not, If they do, that
transaction is never allowed to be executed
Deadlock prevention mechanism
proposes two schemes:
• Wait-Die Scheme:
• Wound Wait Scheme:
Wait-Die Scheme
• In this system, when a transaction (a task that uses data) wants to access something that is
already locked by another transaction, the database checks which one is older based on
their timestamps. The timestamp is simply a record of when the transaction started.
• For example, if there are two transactions, T1 and T2:
1. If T1 is the older transaction (it has an earlier timestamp) and T2 is already using the
resource that T1 wants, T1 will just wait until T2 is done and releases the resource. In other
words, the older transaction waits for the younger one to finish.
2. If T2 is the younger transaction (it started after T1) and T1 is holding a resource that T2
needs, then the database will stop (or kill) T2 and restart it after a small random delay. Even
though T2 is restarted, it keeps its original timestamp so it doesn’t lose its place completely.
• This system is designed to prioritize older transactions, letting them wait if needed, but
younger transactions might be stopped and restarted to avoid conflicts. This way, the older
tasks get preference, and the younger ones are paused and tried again later.
Wound-Wait Scheme
• In the Wound-Wait Scheme, the system decides what to do based on the age
of the transactions (tasks) when they need the same resource.
• Two cases:
1.Older transaction requests a resource held by a younger one:
1. If an older transaction (let’s call it T1) wants something that a younger transaction (T2)
is using, the older one forces the younger one to stop (or "kills" T2).
2. The younger transaction (T2) will be restarted later with a small delay but keeps its
original start time (timestamp). This is called "wounding" the younger transaction.
2.Younger transaction requests a resource held by an older one:
1. If a younger transaction (T2) needs something the older one (T1) is using, the younger
transaction is told to wait until the older one is finished with the resource. In this case,
the younger transaction doesn’t get killed; it just waits.
Disadvantages of deadlock

1.System downtime: Deadlock can cause system downtime, which can result
in loss of productivity and revenue for businesses that rely on the DBMS.
2.Resource waste: When transactions are waiting for resources, these
resources are not being used, leading to wasted resources and decreased
system efficiency.
3.Reduced concurrency: Deadlock can lead to a decrease in system
concurrency, which can result in slower transaction processing and reduced
throughput.
4.Complex resolution: Resolving deadlock can be a complex and time-
consuming process, requiring system administrators to intervene and
manually resolve the deadlock.
5.Increased system overhead: The mechanisms used to detect and resolve
deadlock, such as timeouts and rollbacks, can increase system overhead,
leading to decreased performance.