Co způsobuje uváznutí (deadlock) a jak se mu vyhnete?

Question

Accepted Answer

**Uváznutí** (deadlock) nastane, když si dvě (nebo více) transakce navzájem držují zámky, které si potřebují — ani jedna nemůže pokračovat, jsou uváznuté a čekají na sebe navzájem. Databáze detekují uváznutí a vyřeší jej **zrušením jedné transakce** ("oběť"), která musí být opakována. Pochopení příčin a prevence je důležité pro souběžné aplikace.

## Jak se uváznutí tvoří

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

## Jak databáze zacházejí s uváznutím

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

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

**#1 prevence** je **konzistentní pořadí zámků**: pokud všechny transakce získávají zámky ve stejném pořadí (např. vždy nejnižší id jako první), cyklické čekání se nemůže vytvořit.

## Vzor pro opakování

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

## Proč je to důležité

Uváznutí je důležitá záležitost souběžnosti v databázích — vyskytuje se v jakékoli aplikaci se souběžnými transakcemi, které upravují překrývající se data, a jejich pochopení je cenné znalosti na senior úrovni pro tvorbu robustních souběžných systémů.

Pochopení **příčiny** — dvě transakce si navzájem drží zámky, které si potřebují, čímž vytvářejí cyklické čekání, kde ani jedna nemůže pokračovat — je základem.

Vědět, jak databáze **zachází** s uváznutím (detekuje cyklus a zruší jednu transakci jako oběť, která musí být opakována), je důležité, protože to znamená, že **vaše aplikace musí zpracovávat chyby uváznutí logikou pro opakování** — uváznutí nelze zcela eliminovat, takže odolný souběžný kód zachytí chybu uváznutí a opakuje ji (standardní, důležitý vzor).

**Strategie prevence** jsou klíčová praktická znalost, zejména #1 technika: **konzistentní pořadí zámků** (vždy získávání zámků ve stejném pořadí napříč všemi transakcemi, což ruší podmínku cyklického čekání, která způsobuje uváznutí) — spolu s udržováním krátkých transakcí (krátké držení zámků), přístupem k prostředkům v konzistentním pořadí a vyhýbáním se dlouhým operacím v transakcích.

Protože uváznutí způsobuje skutečné problémy (selhané transakce, chyby, zhoršený výkon) v souběžných aplikacích s databází, a protože pochopení jejich příčiny (cyklické zámky čekání), prevence (zvláště konzistentní pořadí zámků a krátké transakce) a nutnosti logiky pro opakování je to, co vám umožňuje tvorbu robustních souběžných systémů, je porozumění uváznutí cenné znalosti na senior úrovni pro jakoukoli aplikaci se významným souběžným přístupem k databázi — často relevantní operační záležitost a běžné téma pro pokročilý pohovor demonstrujícího porozumění souběžnosti databází a odolnosti.