# Deadlock

An impasse that may result when two or more transactions are waiting for locks held by the other to be released.
ex. ![](Pasted%20image%2020240227130252.png)

## 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.
![](Pasted%20image%2020240227131306.png)

#### Wound-Wait

If an older transaction requests a lock held by a younger one, the younger one is aborted.
![](Pasted%20image%2020240227131321.png)

#### 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

![](Pasted%20image%2020240227131936.png)
![](Pasted%20image%2020240227131954.png)
![](Pasted%20image%2020240227132007.png)

#### Example 2

![](Pasted%20image%2020240227132741.png)
Edge Ti -> Tj, if Ti waiting to lock item locked by Tj
![](Pasted%20image%2020240227132816.png)
Since the WFG contains a cycle, deadlock exists.

#### Example 3

![](Pasted%20image%2020240227133521.png)

- ![](Pasted%20image%2020240227133544.png)
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           |
![](Pasted%20image%2020240227161426.png)

3. ![](Pasted%20image%2020240227161946.png)
There is no deadlock since there are no cycles.

4. ![](Pasted%20image%2020240227162324.png)
There may be a deadlock, since there are multiple cycles in the WFG

# Database Recovery Part 1