Ni nini husababisha deadlocks na unazizuiaje?

Question

Accepted Answer

**Deadlock** hutokea wakati transactions mbili (au zaidi) kila moja inashikilia lock ambayo nyingine inahitaji, hivyo hakuna inayoweza kuendelea — zimekwama zikisubiriana milele. Hifadhidata hutambua deadlocks na huzitatua kwa **kusitisha transaction moja** ("victim"), ambayo lazima ijaribu tena. Kuelewa sababu na uzuiaji ni muhimu kwa programu za concurrent.

## Jinsi deadlock inavyotokea

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

## Jinsi hifadhidata zinavyoshughulikia deadlocks

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

## Mbinu za uzuiaji

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

**Uzuiaji wa #1** ni **mpangilio thabiti wa locks**: ikiwa transactions zote zinapata locks kwa mpangilio ule ule (mfano daima id ya chini kwanza), kusubiriana kwa mzunguko hakuwezi kuunda.

## Mfumo wa kujaribu tena (retry)

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

## Kwa nini ni muhimu

Deadlocks ni suala muhimu la concurrency katika hifadhidata — hutokea katika programu yoyote yenye transactions za concurrent zinazobadilisha data inayoingiliana, na kuzielewa ni maarifa ya thamani ya kiwango cha senior kwa kujenga mifumo imara ya concurrent.

Kuelewa **sababu** — transactions mbili kila moja ikishikilia lock ambayo nyingine inahitaji, ikiunda kusubiriana kwa mzunguko ambapo hakuna inayoweza kuendelea — ni msingi.

Kujua jinsi hifadhidata zinavyo**shughulikia** deadlocks (kutambua mzunguko na kusitisha transaction moja kama victim, ambayo lazima ijaribu tena) ni muhimu kwa sababu inamaanisha **programu yako lazima ishughulikie makosa ya deadlock kwa mantiki ya kujaribu tena** — deadlocks haziwezi kuondolewa kabisa, hivyo msimbo imara wa concurrent hushika kosa la deadlock na kujaribu tena (mfumo wa kawaida, muhimu).

**Mbinu za uzuiaji** ndizo maarifa muhimu ya kivitendo, hasa mbinu ya #1: **mpangilio thabiti wa locks** (daima kupata locks kwa mpangilio ule ule katika transactions zote, ambao huvunja sharti la kusubiriana kwa mzunguko linalosababisha deadlocks) — pamoja na kuweka transactions fupi (kushikilia locks kwa muda mfupi), kufikia rasilimali kwa mpangilio thabiti, na kuepuka operesheni ndefu ndani ya transactions.

Kwa kuwa deadlocks husababisha matatizo halisi (transactions zilizoshindwa, makosa, utendaji uliopungua) katika programu za concurrent za hifadhidata, na kwa kuwa kuelewa sababu yake (kusubiriana kwa locks kwa mzunguko), uzuiaji (hasa mpangilio thabiti wa locks na transactions fupi), na ulazima wa mantiki ya kujaribu tena ndiyo kinachokuwezesha kujenga mifumo imara ya concurrent, kuelewa deadlocks ni maarifa ya thamani ya kiwango cha senior kwa programu yoyote yenye upatikanaji mkubwa wa concurrent wa hifadhidata — wasiwasi wa kiutendaji unaohusika mara kwa mara na mada ya kawaida ya mahojiano ya hali ya juu inayoonyesha uelewa wa concurrency na uimara wa hifadhidata.