Come previeni i deadlock con migliaia di transazioni concorrenti?

Question

IT Interview Practice · Accepted Answer

**Acquisisci i lock in un ordine globale coerente, mantieni le transazioni brevi, abbassa l'isolamento dove è sicuro, e ritenta il perdente quando un deadlock accade comunque.** Un deadlock è un ciclo: la transazione A tiene la riga 1 e attende la riga 2, mentre B tiene la riga 2 e attende la riga 1 — nessuna può procedere, così il DB ne uccide una.

## Il ciclo che devi spezzare

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

## Strategie

- **Ordine di lock coerente.** Se ogni transazione blocca sempre le righe nello stesso ordine (es. primary key crescente), un ciclo è impossibile — A e B prendono entrambe prima la riga 1, così una semplicemente attende. Questa è la leva singola più grande. Un bug classico: un money transfer che blocca i conti in ordine `(from, to)` va in deadlock con il transfer inverso; blocca sempre per `min(id), max(id)`.
- **Transazioni brevi.** Tieni i lock per il minor tempo possibile — fai validazione, chiamate di rete e letture **prima** di `BEGIN`, poi blocca, scrivi e fai `COMMIT` velocemente. Le transazioni lunghe allargano la finestra per i cicli e le attese sui lock.
- **Abbassa l'isolamento dove è sicuro.** `SERIALIZABLE` prende più lock/range lock e va in deadlock più spesso; `READ COMMITTED` (default di Postgres) blocca meno. Usa l'isolamento più debole che soddisfi comunque la correttezza.
- **Retry sul deadlock.** I deadlock sono transitori. Cattura l'errore di deadlock (Postgres `40P01`, MySQL `1213`) e ritenta l'intera transazione con piccolo backoff. Un po' di contesa è inevitabile su larga scala, quindi il retry è una rete di sicurezza, non un sostituto dell'ordinamento.

## Prospettiva del colloquio

L'intervistatore verifica se sai che i deadlock si **prevengono per design, non solo si catturano**. Nominare solo il "retry" è una risposta debole — la risposta eccellente parte da **ordine di lock coerente** e **transazioni brevi**, poi aggiunge il retry per il residuo. Una trappola comune: assumere che l'app debba rilevare i deadlock; in pratica **il DB rileva il ciclo e aborta una vittima** per te — il tuo compito è l'ordinamento più un loop di retry.

**Compromessi:** un ordinamento rigido può essere difficile quando i pattern di accesso sono dinamici o coprono più tabelle; un isolamento più basso rischia anomalie (non-repeatable read) su cui devi ragionare. I loop di retry devono essere **idempotenti** e limitati, altrimenti un conflitto caldo si trasforma in una tempesta di retry. La prevenzione dei deadlock è in realtà disciplina sui lock più un retry limitato, non un'unica soluzione miracolosa.

Il ciclo che devi spezzare

Strategie

Prospettiva del colloquio

Domande correlate