Kaj povzroča deadlock-e in kako jih preprečite?

Question

Accepted Answer

**Deadlock** se pojavi, ko dve (ali več) transakciji vsaka drži zaklepanje, ki ga potrebuje druga, zato nobena ne more napredovati — sta obeploščeni v čakanju drug na drugega v neskončnost. Baze podatkov zaznajo deadlock-e in jih razrešijo z **prekinitvijo ene transakcije** ("žrtve"), ki jo je treba znova poskusiti. Razumevanje vzrokov in preprečevanja je pomembno za sočasne aplikacije.

## Kako se pojavi deadlock

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

## Kako baze podatkov rokovajo z deadlock-i

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

## Strategije preprečevanja

```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 preprečevanje** je **dosledni vrstni red zaklenchanja**: če vse transakcije pridobijo zaklepanja v istem vrstnem redu (npr. vedno najprej nižji id), krožnega čakanja ne more biti.

## Vzorec za ponovni poskus

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

## Zakaj je to pomembno

Deadlock-i so pomembno vprašanje sočasnosti v bazah podatkov — pojavljajo se v kateri koli aplikaciji s sočasnimi transakcijami, ki spreminjajo prekrivajočih se podatkov, in njihovo razumevanje je dragoceno znanje na višji ravni za gradnjo robustnih sočasnih sistemov.

Razumevanje **vzroka** — dve transakciji, ki vsaka drži zaklepanje, ki ga potrebuje druga, kar ustvari krožno čakanje, kjer nobena ne more napredovati — je temelj.

Znanje, kako baze podatkov **rokovajo** z deadlock-i (zaznavanje cikla in prekinitev ene transakcije kot žrtve, ki mora biti znova poskušena), je pomembno, ker pomeni, da **vaša aplikacija mora rokovati z napako deadlock-a z logiko ponovnega poskusa** — deadlock-ov ne moremo popolnoma odpraviti, zato robustna sočasna koda ujame napako deadlock-a in jo poskusi znova (standarden, pomemben vzorec).

**Strategije preprečevanja** so ključno praktično znanje, posebej #1 tehnika: **dosledni vrstni red zaklenchanja** (vedno pridobivanje zaklep v istem vrstnem redu v vseh transakcijah, kar prekine pogoj krožnega čakanja, ki povzroča deadlock-e) — skupaj s kratko trajajočimi transakcijami (kratkotrajno držanje zaklep), dostopom do virov v doslednem vrstnem redu in izogibanjem dolgim operacijam v transakcijah.

Ker deadlock-i povzročajo prave težave (neuspele transakcije, napake, poslabšana učinkovitost) v sočasnih aplikacijah baz podatkov, in ker razumevanje njihovega vzroka (krožna zaklenchanja), preprečevanja (posebej doslednega vrstnega reda zaklenchanja in kratkih transakcij) in nujnosti logike ponovnega poskusa vam omogoča gradnjo robustnih sočasnih sistemov, je razumevanje deadlock-ov dragoceno znanje na višji ravni za vsako aplikacijo s pomembnim sočasnim dostopom do baze podatkov — pogosto prisotna operativna skrb in pogosta napredna tema intervjuja, ki kaže razumevanje sočasnosti baze podatkov in odpornosti.