Hoe voorkom je deadlocks met duizenden gelijktijdige transacties?

Question

IT Interview Practice · Accepted Answer

**Verwerf locks in een consistente globale volgorde, houd transacties kort, verlaag isolatie waar het veilig is, en retry de verliezer wanneer een deadlock toch optreedt.** Een deadlock is een cyclus: transactie A houdt row 1 en wacht op row 2, terwijl B row 2 houdt en op row 1 wacht — geen van beide kan verder, dus de DB doodt er een.

## De cyclus die je moet doorbreken

```text
   Tx A                              Tx B
   houdt row 1  ──── wacht ────▶ row 2 (gehouden door B)
        ▲                              │
        │ wacht                        │ houdt
        └────────── row 1 ◀────────────┘
                (cyclus = deadlock; DB abort één slachtoffer)
```

## Strategieën

- **Consistente lock-volgorde.** Als elke transactie altijd rows in dezelfde volgorde lockt (bijv. oplopende primary key), is een cyclus onmogelijk — A en B pakken beide eerst row 1, dus één wacht simpelweg. Dit is de grootste enkele hefboom. Een klassieke bug: een geldoverdracht die accounts in `(from, to)`-volgorde lockt deadlockt met de omgekeerde overdracht; lock altijd op `min(id), max(id)`.
- **Korte transacties.** Houd locks zo kort mogelijk vast — doe validatie, netwerk-calls en reads **vóór** `BEGIN`, lock dan, schrijf, en `COMMIT` snel. Lange transacties verbreden het venster voor cycli en lock-waits.
- **Verlaag isolatie waar veilig.** `SERIALIZABLE` neemt meer/range-locks en deadlockt vaker; `READ COMMITTED` (Postgres-default) lockt minder. Gebruik de zwakste isolatie die nog aan correctheid voldoet.
- **Retry bij deadlock.** Deadlocks zijn transient. Vang de deadlock-error (Postgres `40P01`, MySQL `1213`) en retry de hele transactie met kleine backoff. Enige contentie is onvermijdelijk op schaal, dus retry is een vangnet, geen vervanging voor ordening.

## Interviewperspectief

De interviewer checkt of je weet dat deadlocks **door ontwerp voorkomen worden, niet alleen opgevangen**. Alleen "retry" benoemen is een zwak antwoord — het uitstekende antwoord leidt met **consistente lock-volgorde** en **korte transacties**, voegt dan retry toe voor het restant. Een veelvoorkomende valkuil: aannemen dat de app deadlocks moet detecteren; in de praktijk **detecteert de DB de cyclus en abort een slachtoffer** voor je — jouw taak is ordening plus een retry-loop.

**Afwegingen:** strikte ordening kan moeilijk zijn wanneer toegangspatronen dynamisch zijn of tabellen overspannen; lagere isolatie riskeert anomalieën (non-repeatable reads) waarover je moet redeneren. Retry-loops moeten **idempotent** en begrensd zijn, anders wordt een hot conflict een retry-storm. Deadlock-preventie is eigenlijk lock-discipline plus een begrensde retry, geen enkele silver bullet.

De cyclus die je moet doorbreken

Strategieën

Interviewperspectief

Gerelateerde vragen