Vad orsakar dödlägen och hur förebygger du dem?

Question

Accepted Answer

Ett **dödläge** inträffar när två (eller fler) transaktioner var och en håller ett lås som den andra behöver, så ingen kan fortsätta — de sitter fast och väntar på varandra för evigt. Databaser detekterar dödlägen och löser dem genom att **avbryta en transaktion** (offret), som måste försöka igen. Att förstå orsakerna och förebyggandet är viktigt för samtidiga applikationer.

## Hur ett dödläge uppstå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
```

## Hur databaser hanterar dödlägen

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

## Förebyggingsstrategier

```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 **viktigaste förebyggingen** är **konsekvent låsordning**: om alla transaktioner hämtar lås i samma ordning (t.ex. alltid det lägre id:t först), kan den cirkulära väntan inte bildas.

## Återförsöksmönstret

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

## Varför det är viktigt

Dödlägen är en viktig samtidighetsfråga i databaser — de inträffar i alla applikationer med samtidiga transaktioner som modifierar överlappande data, och att förstå dem är värdefull kunskap på seniornivå för att bygga robusta samtidiga system.

Att förstå **orsaken** — två transaktioner som var och en håller ett lås som den andra behöver, vilket skapar en cirkulär väntan där ingen kan fortsätta — är grunden.

Att veta hur databaser **hanterar** dödlägen (detekterar cykeln och avbryter en transaktion som ett offer, som måste försöka igen) är viktigt eftersom det betyder att din **applikation måste hantera dödlägsfel med omförsökslogik** — dödlägen kan aldrig elimineras helt, så motståndskraftig samtidig kod fångar dödlägesfelet och försöker igen (ett standardmönster som är viktigt).

**Förebyggingsstrategierna** är den viktigaste praktiska kunskapen, särskilt den viktigaste tekniken: **konsekvent låsordning** (alltid hämta lås i samma ordning över alla transaktioner, vilket bryter det cirkulära väntvillkoret som orsakar dödlägen) — tillsammans med att hålla transaktioner korta (hålla lås under kort tid), få åtkomst till resurser i en konsekvent ordning och undvika långvariga operationer inom transaktioner.

Eftersom dödlägen orsakar riktiga problem (misslyckade transaktioner, fel, försämrad prestanda) i samtidiga databasapplikationer, och eftersom att förstå deras orsak (cirkulära låsväntan), förebyggande (särskilt konsekvent låsordning och korta transaktioner) och nödvändigheten av återförsökslogik är vad som låter dig bygga robusta samtidiga system, är förståelse för dödlägen värdefull kunskap på seniornivå för alla applikationer med betydande samtidig databasåtkomst — en ofta relevant operativ fråga och ett vanligt avancerat intervjuämne som visar förståelse för databaskoncurrens och motståndskraft.