Kako spriječiti deadlockove s tisućama istovremenih transakcija?

Question

IT Interview Practice · Accepted Answer

**Preuzimajte lockove u dosljednom globalnom redoslijedu, držite transakcije kratkima, spustite izolaciju gdje je sigurno i ponovite gubitnika kad se deadlock ipak dogodi.** Deadlock je ciklus: transakcija A drži redak 1 i čeka redak 2, dok B drži redak 2 i čeka redak 1 — nijedna ne može nastaviti, pa baza ubije jednu.

## Ciklus koji morate razbiti

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## Strategije

- **Dosljedan redoslijed zaključavanja.** Ako svaka transakcija uvijek zaključava retke u istom redoslijedu (npr. rastući primarni ključ), ciklus je nemoguć — A i B oboje prvo grabe redak 1, pa jedna jednostavno čeka. Ovo je najveća poluga. Klasičan bug: prijenos novca koji zaključava račune u `(from, to)` redoslijedu deadlockira s obrnutim prijenosom; uvijek zaključavajte po `min(id), max(id)`.
- **Kratke transakcije.** Držite lockove što kraće — radite validaciju, mrežne pozive i čitanja **prije** `BEGIN`, zatim zaključajte, upišite i `COMMIT` brzo. Duge transakcije šire prozor za cikluse i čekanja lockova.
- **Spustite izolaciju gdje je sigurno.** `SERIALIZABLE` uzima više/range lockova i češće deadlockira; `READ COMMITTED` (Postgres zadano) zaključava manje. Koristite najslabiju izolaciju koja i dalje zadovoljava ispravnost.
- **Retry pri deadlocku.** Deadlockovi su prolazni. Uhvatite deadlock grešku (Postgres `40P01`, MySQL `1213`) i ponovite cijelu transakciju s malim backoffom. Nešto borbe je neizbježno na skali, pa je retry sigurnosna mreža, ne zamjena za redoslijed.

## Perspektiva intervjua

Ispitivač provjerava znate li da se deadlockovi **sprječavaju dizajnom, ne samo hvataju**. Imenovanje "retryja" samog je slab odgovor — odličan odgovor vodi s **dosljednim redoslijedom zaključavanja** i **kratkim transakcijama**, zatim dodaje retry za ostatak. Uobičajena zamka: pretpostaviti da aplikacija mora otkriti deadlockove; u praksi **baza otkrije ciklus i prekine žrtvu** za vas — vaš je posao redoslijed plus retry petlja.

**Kompromisi:** strogi redoslijed može biti težak kad su obrasci pristupa dinamični ili obuhvaćaju tablice; niža izolacija riskira anomalije (non-repeatable reads) o kojima morate rasuđivati. Retry petlje moraju biti **idempotentne** i ograničene, ili se vruć konflikt pretvori u oluju retryja. Sprječavanje deadlockova zapravo je disciplina zaključavanja plus ograničen retry, ne jedno srebrno rješenje.

Ciklus koji morate razbiti

Strategije

Perspektiva intervjua

Povezana pitanja