Scribd
Upload
302 views

DBMS Deadlock

Deadlocks occur when two or more transactions are waiting for resources held by each other, creating a cyclic wait. Deadlock detection involves building a wait-for graph to identify cycles that indicate a deadlock. When detected, a victim transaction must be chosen and rolled back to break the deadlock cycle. Prevention techniques include resource ordering, timeouts, wound-wait, and wait-die protocols that impose rules to avoid deadlocks from occurring.

Uploaded by

Rehman Hazrat
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
302 views

DBMS Deadlock

Deadlocks occur when two or more transactions are waiting for resources held by each other, creating a cyclic wait. Deadlock detection involves building a wait-for graph to identify cycles that indicate a deadlock. When detected, a victim transaction must be chosen and rolled back to break the deadlock cycle. Prevention techniques include resource ordering, timeouts, wound-wait, and wait-die protocols that impose rules to avoid deadlocks from occurring.

Uploaded by

Rehman Hazrat
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

DBMS

Deadlock

Deadlocks
Detection
Wait-for graph

Prevention
Resource ordering
Timeout
Wait-die
Wound-wait

Deadlock Detection

Build Wait-For graph


Use lock table structures
Build incrementally or periodically
When cycle found, rollback victim
T2

T1
T4

T3

T5
T6

T7

Deadlock Detection

Deadlocks can be described as a wait-for graph, which consists of a pair G


= (V,E),
V is a set of vertices (all the transactions in the system)
E is a set of edges; each element is an ordered pair Ti Tj.

If Ti Tj is in E, then there is a directed edge from Ti to Tj


implying that Ti is waiting for Tj to release a data item.

When Ti requests a data item held by Tj, then Ti Tj is inserted in the waitfor graph.
This edge is removed only when Tj is no longer holding a data item
needed by Ti.

The system is in a deadlock state if and only if the wait-for graph has a
cycle.
The system invokes a deadlock-detection algorithm periodically to look for
cycles.

Wait-for graph without a cycle

Wait-for graph with a cycle

Deadlock Recovery

When deadlock is detected:


Some transaction will have to rolled back (made a victim) to
break deadlock.
Select that transaction as victim that will incur minimum cost.
Rollback -- determine how far to roll back transaction
Total rollback: Abort the transaction and then restart it.
Partial rollback: More effective to roll back transaction only as
far as necessary to break deadlock.
Starvation happens if same transaction is always chosen as
victim.
The system may include the number of rollbacks in the cost
factor to avoid starvation

Deadlock Handling

System is deadlocked if there is a set of transactions such that every


transaction in the set is waiting for another transaction in the set.
Deadlock prevention protocols ensure that the system will never
enter into a deadlock state.
Some prevention strategies :
Require that each transaction locks all its data items before it
begins execution (predeclaration).
Impose partial ordering of all data items
require that a transaction can lock data items only in the order
specified by the partial order (graph-based protocol).
Timeout-Based Schemes :
a transaction waits for a lock only for a specified amount of
time.
After the wait time is out and the transaction is rolled back.
(No deadlock!)
simple to implement; but starvation is possible
Also difficult to determine good value of the timeout interval.
Use timestamping (in the next slide)

Deadlock Handling

Consider the following two transactions:


T1:
write (X)
T2: write(Y)
write(Y)
Schedule with deadlock

T1
lock-X on X
write (X)

wait for lock-X on Y


write(Y)

write(X)

T2

lock-X on Y
write (Y)
wait for lock-X on X
write(X)

Deadlock Prevention with


Timestamps
Following schemes use transaction timestamps for the sake of deadlock
prevention alone.
Wait-die scheme non-preemptive
Older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.
A transaction may die several times before acquiring needed data
item
Wound-wait scheme preemptive
Older transaction wounds (forces rollback of) younger transaction
instead of waiting for it.
Younger transactions may wait for older ones.
May be fewer rollbacks than wait-die scheme.
Both in wait-die and in wound-wait schemes, a rolled back transaction
is restarted with its original timestamp.
Older transactions thus have precedence over newer ones in these
schemes, and starvation is hence avoided.

Deadlock in DBMSs
What is a deadlock?

A cycle of transactions, T1, T2, ... , Tn=T1 where each Ti is


waiting for Ti-1 to release a lock.
Causes these transactions to sleep forever.

A Deadlock can happen whenever you allow a


transaction to wait for a lock, even with strict two
phase locking.
Simple
T1:example:
R(B),
W(A)
T2: R(A),
W(B)

Users can eliminate deadlocks by accessing resources


in a fixed order.
DBMSs typically detect deadlocks and abort the
transaction that (it thinks) has used the least resources.

Review: The ACID properties


Recovery
Atomicity: All actions in the transaction happen in their
System
entirety or none of them happen.

Programmers

Consistency:

If each transaction is consistent, and the

DB

Concurrency
starts in a consistent state, it ends in a
Control
consistent state.
System

Recovery Isolation:
System

Durability:
persist.

Execution of one transaction is isolated from


that of other transactions.
If a transaction commits, its effects

You might also like