Cosa causa i deadlock e come li previeni?

Question

Accepted Answer

Un **deadlock** si verifica quando due (o più) transazioni ciascuna detengono un lock di cui l'altra ha bisogno, quindi nessuna può procedere — rimangono bloccate in attesa l'una dell'altra per sempre. I database rilevano i deadlock e li risolvono **abortendo una transazione** (la "vittima"), che deve ritentare. Comprendere le cause e la prevenzione è importante per le applicazioni concorrenti.

## Come si verifica un deadlock

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

## Come i database gestiscono i deadlock

```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.
```

## Strategie di prevenzione

```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)
```

La **prevenzione #1** è l'**ordinamento consistente dei lock**: se tutte le transazioni acquisiscono i lock nello stesso ordine (ad es. sempre l'id più basso per primo), l'attesa circolare non può formarsi.

## Il pattern di retry

```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.
```

## Perché è importante

I deadlock sono un problema importante di concorrenza nei database — si verificano in qualsiasi applicazione con transazioni concorrenti che modificano dati sovrapposti, e comprenderli è una conoscenza preziosa di livello senior per costruire sistemi concorrenti robusti.

Comprendere la **causa** — due transazioni ciascuna che detengono un lock di cui l'altra ha bisogno, creando un'attesa circolare dove nessuna può procedere — è il fondamento.

Sapere come i database **gestiscono** i deadlock (rilevando il ciclo e abortendo una transazione come vittima, che deve ritentare) è importante perché significa che la tua **applicazione deve gestire gli errori di deadlock con logica di retry** — i deadlock non possono essere completamente eliminati, quindi il codice concorrente resiliente cattura l'errore di deadlock e ritenta (un pattern standard, importante).

Le **strategie di prevenzione** sono la conoscenza pratica chiave, soprattutto la tecnica #1: l'**ordinamento consistente dei lock** (acquisire sempre i lock nello stesso ordine in tutte le transazioni, il che rompe la condizione di attesa circolare che causa i deadlock) — insieme al mantenimento delle transazioni brevi (mantenere i lock brevemente), accedere alle risorse in un ordine consistente, ed evitare operazioni lunghe all'interno delle transazioni.

Poiché i deadlock causano problemi reali (transazioni fallite, errori, prestazioni degradate) nelle applicazioni database concorrenti, e poiché comprendere la loro causa (attese circolari di lock), prevenzione (in particolare ordinamento consistente dei lock e transazioni brevi), e la necessità della logica di retry è ciò che ti permette di costruire sistemi concorrenti robusti, comprendere i deadlock è una conoscenza preziosa di livello senior per qualsiasi applicazione con accesso concorrente significativo al database — una preoccupazione operazionale frequentemente rilevante e un argomento avanzato comune in interviste che dimostra comprensione della concorrenza del database e della resilienza.