Kas sukelia aklavietės ir kaip jas išvengti?

Question

Accepted Answer

**Aklavietė** atsiranda, kai dvi (arba daugiau) transakcijos kiekviena laiko fechą, kurios reikalinga kitai, todėl nei viena negali tęsti — jos застревают laukdamos viena kitos amžinai. Duomenų bazės aptinka aklavietės ir jas išsprendžia **nutraukiant vieną transakciją** ("aukos"), kuri turi iš naujo bandyti. Suprasti priežastis ir prevenciją yra svarbu konkuruojančioms aplikacijoms.

## Kaip susidaro aklavietė

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

## Kaip duomenų bazės tvarkosi su aklavietėmis

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

## Prevencijos strategijos

```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 prevencija** yra **nuosekli fechų eilutė**: jei visos transakcijos gauna fechas ta pačia tvarka (pvz., visada pirma žemesnė id), ciklinis laukimas negali susiformuoti.

## Pakartojimo šablonas

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

## Kodėl tai svarbu

Aklavietės yra svarbi konkurencijos problema duomenų bazėse — jos atsiranda bet kurioje aplikacijoje su konkuruojančiomis transakcijomis, kurios modifikuoja sutampančius duomenis, ir jų supratimas yra vertinga aukštos kvalifikacijos žinios saugių konkurencijos sistemų kūrimui.

Supratimas apie **priežastį** — dvi transakcijos kiekviena laikydamos fechą, kurios reikalinga kitai, sukurdamos ciklinį laukimą, kuriame nei viena negali tęsti — yra pagrindas.

Žinoti, kaip duomenų bazės **tvarko** aklavietės (aptinkant ciklą ir nutraukiant vieną transakciją kaip auką, kuri turi iš naujo bandyti) yra svarbu, nes tai reiškia, kad jūsų **aplikacija turi tvirtinti aklavietės klaidas su pakartojimo logika** — aklavietės negali būti visiškai pašalintos, todėl patvarūs konkurencijos kodai padaro aklavietės klaidą ir pakartoja (standartinis, svarbus šablonas).

**Prevencijos strategijos** yra pagrindinės praktinės žinios, ypač #1 technika: **nuosekli fechų eilutė** (visuomet gaunant fechas ta pačia tvarka visuose transakcijose, kas sulaužo ciklinį laukimą, kuris sukelia aklavietės) — kartu su trumpų transakcijų palaikymu (trumpai laikant fechas), išteklių prieiga nuoseklia tvarka ir vengimu ilgų operacijų transakcijose.

Kadangi aklavietės sukelia tikras problemas (nepavykusios transakcijos, klaidos, pablogėjusias veikimas) konkuruojančiose duomenų bazės aplikacijose, ir kadangi jų priežasties supratimas (ciklinis fechų laukimas), prevencija (ypač nuosekli fechų eilutė ir trumpos transakcijos) ir būtinybė pakartojimo logika leidžia jums kurti patvarūs konkurencijos sistemus, aklavietės supratimas yra vertinga aukštos kvalifikacijos žinios bet kurioje aplikacijoje su reikšmingu konkuruojančiu duomenų bazės prieiga — dažnai aktualus operacinis klausimas ir dažnas išplėstinis interviu klausimas, parodantis duomenų bazės konkurencijos ir patvaraus veikimo supratimą.