Hvad forårsager deadlocks, og hvordan forhindrer du dem?

Question

Accepted Answer

En **deadlock** opstår, når to (eller flere) transaktioner hver i sær holder en lås, som den anden har brug for, så ingen af dem kan fortsætte — de er fastlåst og venter på hinanden for evigt. Databaser opdager deadlocks og løser dem ved at **afbryde en transaktion** (ofret), som derefter skal køres igen. At forstå årsagerne og forebyggelsen er vigtig for samtidige applikationer.

## Hvordan en deadlock opstå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.
```

## Forebyggelsesstrategier

```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 **vigtigste forebyggelse** er **konsistent låsordning**: hvis alle transaktioner erhverver låse i samme rækkefølge (f.eks. altid det laveste id først), kan den cirkulære venten ikke dannes.

## Retry-mø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 betyder noget

Deadlocks er et vigtigt samburedseproblem i databaser — de opstår i enhver applikation med samtidige transaktioner, der ændrer overlappende data, og at forstå dem er værdifuld senior-level viden for at bygge robuste samtidige systemer.

At forstå **årsagen** — to transaktioner, der hver i sær holder en lås, som den anden har brug for, hvilket skaber en cirkulær venten, hvor ingen kan fortsætte — er grundlaget.

At vide, hvordan databaser **håndterer** deadlocks (opdager cyklussen og afbryder en transaktion som offer, som skal køres igen), er vigtig, fordi det betyder, at din **applikation skal håndtere deadlock-fejl med retry-logik** — deadlocks kan ikke helt elimineres, så robust samtidige kode fanger deadlock-fejlen og prøver igen (et standard, vigtig mønster).

De **forebyggelsesstrategier** er nøglens praktiske viden, især den vigtigste teknik: **konsistent låsordning** (altid erhvervelse af låse i samme rækkefølge på tværs af alle transaktioner, hvilket bryder den cirkulære-vente-tilstand, der forårsager deadlocks) — sammen med at holde transaktioner kort (holde låse i kort tid), adgang til ressourcer i en konsistent rækkefølge, og undgå lange operationer inden for transaktioner.

Fordi deadlocks forårsager rigtige problemer (fejlslagne transaktioner, fejl, forringet ydeevne) i samtidige databaseapplikationer, og fordi at forstå deres årsag (cirkulære låsventer), forebyggelse (især konsistent låsordning og korte transaktioner), og nødvendigheden af retry-logik er det, der lader dig bygge robuste samtidige systemer, er det at forstå deadlocks værdifuld senior-level viden for enhver applikation med betydelig samtidsadgang til database — en ofte relevant operativ bekymring og et almindeligt avanceret interviewemne, der demonstrerer forståelse af databaser samtidighed og robusthed.