DBMS Topics
Deadlock in DBMS
Last Updated : 21 May, 2026
A deadlock is a situation where two or more transactions are waiting indefinitely for each other to release locks — creating a circular wait that can never be resolved wi
What is a Deadlock?
A deadlock is a situation where two or more transactions are waiting indefinitely for each other to release locks — creating a circular wait that can never be resolved without external intervention.
Deadlock Conditions (Coffman Conditions)
All four must hold simultaneously for a deadlock to occur:
- Mutual Exclusion: Resources cannot be shared (exclusive locks)
- Hold and Wait: Transactions hold some locks while waiting for others
- No Preemption: Locks cannot be forcibly taken from a transaction
- Circular Wait: A cycle exists in the wait-for graph
Deadlock Detection — Wait-For Graph
A Wait-For Graph (WFG) detects deadlocks:
- Nodes: Each transaction is a node
- Edges: Ti → Tj means Ti is waiting for a resource held by Tj
A deadlock exists if and only if the WFG has a cycle.
Example
T1 waits for lock held by T2
T2 waits for lock held by T3
T3 waits for lock held by T1
Wait-For Graph
T1 ──► T2 ──► T3
▲ │
└──────────────┘
CYCLE: T1 → T2 → T3 → T1 → DEADLOCK DETECTED
Detection Algorithm
Deadlock Handling Strategies
Strategy 1: Deadlock Detection + Recovery
Most practical DBMS approach.
Detection
- Periodically check WFG for cycles
- OR use timeout: if transaction waits too long → assume deadlock
Recovery (Victim Selection)
- Choose transaction that minimizes cost to rollback:
• Transaction that has done least work
• Transaction that holds fewest locks
• Transaction with lowest priority
• Transaction that has been rolled back least recently (to avoid starvation)
Rollback
- Total rollback: abort entire transaction
- Partial rollback: roll back to a savepoint where the cycle is broken
Strategy 2: Deadlock Prevention
Design protocols that prevent deadlock from ever occurring.
Method 1 — Wait-Die (Non-preemptive)
Method 2 — Wound-Wait (Preemptive)
If T1 (older) wants lock held by T2 (younger)
T1 WOUNDS T2 (forces T2 to abort and restart)
T1 gets the lock
If T1 (younger) wants lock held by T2 (older)
T1 WAITS (younger waits for older)
"Old transactions wound (preempt); young transactions wait"
→ Only younger transactions wait → no cycles possible
Comparison
Strategy 3: Deadlock Avoidance
Use extra information about future lock requests to avoid unsafe states.
Banker's Algorithm (adapted for DBMS):
- Maintain safe state: a state where all transactions can complete
- Before granting a lock, check if the system remains in a safe state
- If granting the lock leads to unsafe state → deny (transaction waits)
Rarely used in DBMS due to high overhead.
Strategy 4: Lock Ordering (Prevention)
Require all transactions to acquire locks in a predefined global order.
| Global order | A < B < C < D |
| T1 | lock(A), lock(C) ✓ (A before C) |
| T2 | lock(B), lock(D) ✓ (B before D) |
| T3 | lock(A), lock(D) ✓ (A before D) |
| ILLEGAL | T4: lock(C), then lock(A) ← violates order |
Starvation
A transaction experiences starvation if it waits indefinitely while other transactions are repeatedly preferred over it.
Solution: Use FIFO waiting queues — grant locks in the order they were requested.
Deadlock Summary
| Detection | Periodically check WFG for cycles; abort victim |
| Wait-Die | Older waits, Younger aborts |
| Wound-Wait | Older preempts Younger, Younger waits |
| Lock Order | All transactions acquire locks in global order |
| Avoidance | Banker's Algorithm (theoretical, rarely used) |
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Deadlock in DBMS.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this DBMS topic.
Search Terms
dbms, database management system, database notes, sql, unit, deadlock, deadlock in dbms
Related DBMS Topics