Hva forårsaker deadlocks og hvordan forhindrer du dem?

Question

Accepted Answer

En **deadlock** oppstår når to (eller flere) transaksjoner hver holder en lås som den andre trenger, så ingen kan fortsette — de er fast låst og venter på hverandre for alltid. Databaser oppdager deadlocks og løser dem ved å **avbryte en transaksjon** ("offeret"), som må prøves på nytt. Å forstå årsakene og forebyggingen er viktig for samtidige applikasjoner.

## Hvordan en deadlock oppstår

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

## Hvordan databaser håndterer deadlocks

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

## Forebyggingsstrategier

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

Den **#1 forebyggingen** er **konsistent låseordning**: hvis alle transaksjoner erverber låser i samme rekkefølge (f.eks. alltid den lavere id først), kan den sirkulære ventefasen ikke dannes.

## Gjentaksmønsteret

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

## Hvorfor det betyr noe

Deadlocks er et viktig samvariasjonsinitiativ i databaser — de oppstår i enhver applikasjon med samtidige transaksjoner som endrer overlappende data, og å forstå dem er verdifull senior-nivå-kunnskap for å bygge robuste samtidige systemer.

Å forstå **årsaken** — to transaksjoner som hver holder en lås den andre trenger, og skaper en sirkulær venting der ingen kan fortsette — er grunnlaget.

Å vite hvordan databaser **håndterer** deadlocks (oppdager syklusen og avbryter en transaksjon som offer, som må prøves på nytt) er viktig fordi det betyr at **applikasjonen din må håndtere deadlock-feil med gjentakslogikk** — deadlocks kan ikke elimineres fullstendig, så motstandsdyktig samtdig kode fanger deadlock-feilen og prøver på nytt (et standard, viktig mønster).

**Forebyggingsstrategiene** er nøkkelen til praktisk kunnskap, spesielt teknikk nr. 1: **konsistent låseordning** (alltid erverve låser i samme rekkefølge på tvers av alle transaksjoner, som bryter den sirkulære-vente-tilstanden som forårsaker deadlocks) — sammen med å holde transaksjoner korte (holde låser kort tid), få tilgang til ressurser i en konsistent rekkefølge, og unngå lange operasjoner innenfor transaksjoner.

Siden deadlocks forårsaker reelle problemer (mislykkede transaksjoner, feil, forverret ytelse) i samtidige databaseapplikasjoner, og siden å forstå deres årsak (sirkulære låseventer), forebygging (spesielt konsistent låseordning og korte transaksjoner), og nødvendigheten av gjentakslogikk er det som lar deg bygge robuste samtidige systemer, er å forstå deadlocks verdifull senior-nivå-kunnskap for enhver applikasjon med betydelig samttig databaseaksess — et hyppig relevant operativt anliggende og et vanlig avansert intervjuemne som demonstrerer forståelse av databasesamvariasjon og motstandsdyktighet.