Wat veroorzaakt deadlocks en hoe voorkom je ze?

Question

Accepted Answer

Een **deadlock** treedt op wanneer twee (of meer) transacties elk een lock hebben die de ander nodig heeft, zodat geen van beide kan doorgaan — ze zitten vast en wachten voor altijd op elkaar. Databases detecteren deadlocks en lossen ze op door **één transactie af te breken** (het "slachtoffer"), die opnieuw moet proberen. Het begrijpen van de oorzaken en preventie is belangrijk voor gelijktijdige applicaties.

## Hoe een deadlock ontstaat

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## Hoe databases deadlocks aanpakken

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## Preventiestrategie

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

De **#1 preventie** is **consistente lock-ordening**: als alle transacties locks in dezelfde volgorde verkrijgen (bv. altijd eerst de lagere id), kan de circulaire wachttoestand niet ontstaan.

## Het retry-patroon

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## Waarom het belangrijk is

Deadlocks zijn een belangrijk gelijktijdigheidspreoccupatie in databases — ze treden op in elke applicatie met gelijktijdige transacties die overlappende gegevens wijzigen, en het begrijpen ervan is waardevolle kennis op seniorenniveau voor het bouwen van robuuste gelijktijdige systemen.

Het begrijpen van de **oorzaak** — twee transacties die elk een lock hebben die de ander nodig heeft, wat een circulaire wachttoestand creëert waarin geen van beide kan doorgaan — is de basis.

Weten hoe databases **deadlocks aanpakken** (de cyclus detecteren en één transactie als slachtoffer afbreken, die opnieuw moet proberen) is belangrijk omdat het betekent dat je **applicatie deadlock-fouten met retry-logica moet afhandelen** — deadlocks kunnen niet volledig worden geëlimineerd, dus robuuste gelijktijdige code vangt de deadlock-fout op en probeert opnieuw (een standaard, belangrijk patroon).

De **preventiestrategie
ën** zijn de belangrijkste praktische kennis, vooral de #1-techniek: **consistente lock-ordening** (locks altijd in dezelfde volgorde verkrijgen in alle transacties, wat de circulaire-wachttoestand die deadlocks veroorzaakt doorbreekt) — samen met het kort houden van transacties (locks kort vasthouden), resources in een consistente volgorde benaderen, en lange operaties binnen transacties vermijden.

Omdat deadlocks echte problemen veroorzaken (mislukte transacties, fouten, verslechterde prestaties) in gelijktijdige database-applicaties, en omdat het begrijpen van hun oorzaak (circulaire lock-wachttijden), preventie (vooral consistente lock-ordening en korte transacties), en de noodzaak van retry-logica je in staat stelt om robuuste gelijktijdige systemen te bouwen, is het begrijpen van deadlocks waardevolle kennis op seniorenniveau voor elke applicatie met significante gelijktijdige database-toegang — een regelmatig relevant operationeel gegeven en een veelgebruikt geavanceerd interview-onderwerp dat begrip aantoont van gelijktijdigheid in databases en veerkracht.