Unazuiaje deadlocks na maelfu ya concurrent transactions?

Question

IT Interview Practice · Accepted Answer

**Chukua locks kwa consistent global order, weka transactions fupi, punguza isolation pale ilipo salama, na jaribu tena aliyeshinda wakati deadlock bado inatokea.** Deadlock ni cycle: transaction A hushikilia row 1 na husubiri row 2, huku B ikishikilia row 2 na kusubiri row 1 — hakuna inayoweza kuendelea, hivyo DB huua moja.

## Cycle unayolazimika kuvunja

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## Strategies

- **Consistent lock ordering.** Ikiwa kila transaction daima hulock rows kwa mpangilio ule ule (mfano ascending primary key), cycle haiwezekani — A na B zote zinanyakua row 1 kwanza, hivyo moja husubiri tu. Hii ndiyo lever kubwa zaidi. Bug ya kawaida: money transfer inayolock accounts kwa `(from, to)` order hu-deadlock na reverse transfer; daima lock kwa `min(id), max(id)`.
- **Short transactions.** Shikilia locks kwa muda mfupi iwezekanavyo — fanya validation, network calls, na reads **kabla** ya `BEGIN`, kisha lock, andika, na `COMMIT` kwa haraka. Long transactions hupanua window kwa cycles na lock waits.
- **Punguza isolation pale salama.** `SERIALIZABLE` huchukua locks nyingi/range na hu-deadlock zaidi; `READ COMMITTED` (Postgres default) hulock kidogo. Tumia isolation dhaifu zaidi inayotimiza usahihi bado.
- **Retry kwenye deadlock.** Deadlocks ni za muda. Kamata deadlock error (Postgres `40P01`, MySQL `1213`) na jaribu tena transaction nzima kwa backoff ndogo. Contention fulani haiepukiki kwenye scale, hivyo retry ni safety net, si mbadala wa ordering.

## Mtazamo wa mahojiano

Mhojiwa hukagua kama unajua deadlocks **huzuiwa kwa design, si tu kukamatwa**. Kutaja "retry" peke yake ni jibu dhaifu — jibu bora sana huanza na **consistent lock ordering** na **short transactions**, kisha huongeza retry kwa residual. Mtego wa kawaida: kudhani app lazima igundue deadlocks; kivitendo **DB hugundua cycle na kuua victim** kwa niaba yako — kazi yako ni ordering pamoja na retry loop.

**Maelewano:** strict ordering inaweza kuwa ngumu wakati access patterns ni dynamic au zinavuka tables; isolation ya chini huhatarisha anomalies (non-repeatable reads) unazopaswa kuzifikiria. Retry loops lazima ziwe **idempotent** na zenye cap, la sivyo hot conflict huwa retry storm. Deadlock prevention kwa kweli ni lock-discipline pamoja na bounded retry, si silver bullet moja.

Cycle unayolazimika kuvunja

Strategies

Mtazamo wa mahojiano

Maswali yanayohusiana