Co powoduje zastoje (deadlock) i jak im zapobiegać?

Question

Accepted Answer

**Zastój (deadlock)** występuje, gdy dwie (lub więcej) transakcje każda posiada blokadę, której potrzebuje druga, więc żadna nie może się posunąć — są zablokowane czekając na siebie nawzajem w nieskończoność. Bazy danych wykrywają zastoje i rozwiązują je przez **przerwanie jednej transakcji** ("ofiary"), którą trzeba ponowić. Zrozumienie przyczyn i zapobiegania jest ważne dla aplikacji współbieżnych.

## Jak dochodzi do zastoju

```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 bazy danych obsługują zastoje

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

```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 zapobieganie** to **spójne zamawianie blokad**: jeśli wszystkie transakcje nabywają blokady w tej samej kolejności (np. zawsze najpierw niższy id), cykliczne czekanie nie może się utworzyć.

## Wzorzec ponowienia

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

## Dlaczego to ważne

Zastoje są ważnym zagadnieniem współbieżności w bazach danych — występują w każdej aplikacji z konkurencyjnymi transakcjami modyfikującymi overlappujące dane, a zrozumienie ich jest cenną wiedzą na poziomie seniora dla budowania niezawodnych systemów współbieżnych.

Zrozumienie **przyczyny** — dwie transakcje, każda posiadająca blokadę potrzebną drugiej, tworząc cykliczne czekanie gdzie żadna nie może się posunąć — jest fundamentem.

Wiedza jak bazy danych **obsługują** zastoje (wykrywając cykl i przerywając jedną transakcję jako ofiarę, która musi być ponowiona) jest ważna, ponieważ oznacza to że **aplikacja musi obsługiwać błędy zastojów logiką ponowienia** — zastoje nie mogą być całkowicie wyeliminowane, więc niezawodny kod współbieżny przechwytuje błąd zastoju i ponawia (standardowy, ważny wzorzec).

**Strategie zapobiegania** to kluczowa praktyczna wiedza, szczególnie technika #1: **spójne zamawianie blokad** (zawsze nabywanie blokad w tej samej kolejności we wszystkich transakcjach, co przerywa warunek cyklicznego czekania powodujący zastoje) — wraz z krótkim czasem trwania transakcji (krótkie posiadanie blokad), dostępem do zasobów w spójnej kolejności i unikaniem długich operacji w transakcjach.

Ponieważ zastoje powodują rzeczywiste problemy (nieudane transakcje, błędy, pogorszona wydajność) w współbieżnych aplikacjach bazodanowych, i ponieważ zrozumienie ich przyczyny (cykliczne czekania na blokady), zapobiegania (szczególnie spójne zamawianie blokad i krótkie transakcje), i konieczności logiki ponowienia pozwala budować niezawodne systemy współbieżne, zrozumienie zastawów jest cenną wiedzą na poziomie seniora dla każdej aplikacji ze znaczącym współbieżnym dostępem do bazy danych — częsty problem operacyjny i popularny zaawansowany temat rozmowy kwalifikacyjnej demonstrujący zrozumienie współbieżności bazy danych i niezawodności.