Hvordan hindrer du deadlocks med tusenvis av samtidige transaksjoner?

Question

IT Interview Practice · Accepted Answer

**Anskaff locks i en konsistent global rekkefølge, hold transaksjoner korte, senk isolasjon der det er trygt, og retry taperen når en deadlock likevel skjer.** En deadlock er en syklus: transaksjon A holder rad 1 og venter på rad 2, mens B holder rad 2 og venter på rad 1 — ingen kan fortsette, så DB-en dreper en.

## Syklusen du må bryte

```text
   Tx A                              Tx B
   holder rad 1  ──── venter ────▶ rad 2 (holdt av B)
        ▲                              │
        │ venter                       │ holder
        └────────── rad 1 ◀────────────┘
                (syklus = deadlock; DB aborterer ett offer)
```

## Strategier

- **Konsistent lock-rekkefølge.** Hvis hver transaksjon alltid locker rader i samme rekkefølge (f.eks. stigende primary key), er en syklus umulig — A og B griper begge rad 1 først, så én venter bare. Dette er den enkeltstørste spaken. En klassisk bug: en pengeoverføring som locker kontoer i `(from, to)`-rekkefølge deadlocker med den motsatte overføringen; lock alltid på `min(id), max(id)`.
- **Korte transaksjoner.** Hold locks så kort tid som mulig — gjør validering, nettverkskall og lesninger **før** `BEGIN`, deretter lock, write, og `COMMIT` raskt. Lange transaksjoner utvider vinduet for sykluser og lock-ventinger.
- **Senk isolasjon der trygt.** `SERIALIZABLE` tar flere/range-locks og deadlocker mer; `READ COMMITTED` (Postgres-standard) locker mindre. Bruk den svakeste isolasjonen som fortsatt møter korrekthet.
- **Retry ved deadlock.** Deadlocks er forbigående. Fang deadlock-feilen (Postgres `40P01`, MySQL `1213`) og retry hele transaksjonen med liten backoff. Noe contention er uunngåelig i skala, så retry er et sikkerhetsnett, ikke en erstatning for rekkefølge.

## Intervjuperspektiv

Intervjueren sjekker om du vet at deadlocks **forhindres ved design, ikke bare fanges**. Å navngi "retry" alene er et svakt svar — det utmerkede svaret leder med **konsistent lock-rekkefølge** og **korte transaksjoner**, deretter legger til retry for det gjenværende. En vanlig felle: å anta at appen må detektere deadlocks; i praksis **detekterer DB-en syklusen og aborterer et offer** for deg — din jobb er rekkefølge pluss en retry-loop.

**Avveininger:** streng rekkefølge kan være vanskelig når aksessmønstre er dynamiske eller spenner over tabeller; lavere isolasjon risikerer anomalier (non-repeatable reads) du må resonnere om. Retry-loops må være **idempotente** og cappet, ellers blir en hot konflikt til en retry-storm. Deadlock-forhindring er egentlig lock-disiplin pluss en avgrenset retry, ikke en enkelt sølvkule.

Syklusen du må bryte

Strategier

Intervjuperspektiv

Relaterte spørsmål