114 lines
3.7 KiB
Markdown
114 lines
3.7 KiB
Markdown
# Deadlock
|
|
|
|
An impasse that may result when two or more transactions are waiting for locks held by the other to be released.
|
|
ex. 
|
|
|
|
## Breaking a Deadlock
|
|
|
|
Abort one or more transactions.
|
|
If deadlock occurs, DBMS will
|
|
|
|
- Automatically abort one transaction
|
|
- Release locks, allow other transactions to continue
|
|
- Restart aborted transaction
|
|
|
|
## Handling Deadlock
|
|
|
|
- Timeouts
|
|
- Prevention
|
|
- Detection and recovery
|
|
|
|
### Timeouts
|
|
|
|
Transactions that request a lock will only wait a system-defined amount of time.
|
|
If lock not granted within the period,
|
|
|
|
- Lock request times out
|
|
- DBMS assumes deadlock
|
|
- Transaction aborted and restarted
|
|
|
|
### Prevention
|
|
|
|
DBMS looks ahead to see if a transaction causes deadlock.
|
|
Order transactions using transaction timestamps with the following methods:
|
|
|
|
#### Wait-Die
|
|
|
|
Only older transaction can wait for a younger one.
|
|
If a younger transaction requests a lock held by an older one, the younger one is aborted then restarted with the same timestamp, so will eventually become the oldest active transaction and will not die.
|
|
|
|
|
|
#### Wound-Wait
|
|
|
|
If an older transaction requests a lock held by a younger one, the younger one is aborted.
|
|
|
|
|
|
#### Summary of Prevention Techniques
|
|
|
|
Deadlock free
|
|
Wait-Die, transactions only wait for younger transactions, no cycle
|
|
Wound-Wait, transactions only wait for older transactions, no cycle
|
|
Both may cause transactions to be aborted and restarted needlessly, even if they would not cause a deadlock.
|
|
|
|
### Deadlock Prevention and Recovery
|
|
|
|
DBMS allows deadlock to occur, recognises and breaks it.
|
|
DBMS uses a wait-for-graph (WFG) that shows transaction dependencies
|
|
A WFG is generated by creating a node for each transaction, and an edge ( Ti -> Tj ). If Ti is waiting to lock an item locked by Tj.
|
|
Deadlock exists if the WFG contains a cycle.
|
|
A WFG is created at regular intervals
|
|
|
|
#### Wait-For-Graph Example 1
|
|
|
|
|
|
|
|
|
|
|
|
#### Example 2
|
|
|
|
|
|
Edge Ti -> Tj, if Ti waiting to lock item locked by Tj
|
|
|
|
Since the WFG contains a cycle, deadlock exists.
|
|
|
|
#### Example 3
|
|
|
|
|
|
|
|
- 
|
|
Graph contains several cycles, deadlock exists
|
|
|
|
#### Recovery
|
|
|
|
Several issues that DBMS needs to address
|
|
|
|
- Selecting deadlock victim that will minimise cost of breaking deadlock
|
|
- May be better to abort transaction that has just started, rather than one that has been running longer.
|
|
- May be better to abort transaction that makes little change to database, rather than one that makes a significant change
|
|
- Avoiding starvation
|
|
- Occurs when same transaction is chosen as victim, preventing completion
|
|
- DBMS may try to avoid this by storing a count of abortions of a transaction.
|
|
|
|
# Tutorial
|
|
|
|
1. .
|
|
1. Deadlock occurs when one or more transactions are held by each other, and neither can continue
|
|
2. The DBMS detects deadlock by utilising a WFG, and checking for cycles
|
|
3. The only way to break a deadlock is by aborting one or more transaction.
|
|
2. .
|
|
|
|
| Transaction | Locked | Waiting For |
|
|
| ----------- | ------ | ----------- |
|
|
| T1 | X | |
|
|
| T2 | Z | |
|
|
| T3 | | Z |
|
|
|
|
|
|
3. 
|
|
There is no deadlock since there are no cycles.
|
|
|
|
4. 
|
|
There may be a deadlock, since there are multiple cycles in the WFG
|
|
|
|
# Database Recovery Part 1
|