હજારો concurrent transactions સાથે તમે deadlocks કેવી રીતે અટકાવશો?

Question

IT Interview Practice · Accepted Answer

**locks ને consistent global order માં acquire કરો, transactions ટૂંકા રાખો, જ્યાં safe હોય ત્યાં isolation ઘટાડો, અને deadlock છતાં થાય તો loser ને retry કરો.** deadlock એ એક cycle છે: transaction A row 1 ધરાવે છે અને row 2 ની રાહ જુએ છે, જ્યારે B row 2 ધરાવે છે અને row 1 ની રાહ જુએ છે — કોઈ આગળ વધી શકતું નથી, તેથી DB એક ને મારે છે.

## તમારે તોડવો પડતો cycle

```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.** જો દરેક transaction હંમેશા rows ને એ જ order માં lock કરે (દા.ત. ascending primary key), તો cycle અશક્ય છે — A અને B બંને પહેલા row 1 પકડે, તેથી એક ફક્ત રાહ જુએ. આ સૌથી મોટો lever છે. Classic bug: એક money transfer જે accounts ને `(from, to)` order માં lock કરે તે reverse transfer સાથે deadlock કરે; હંમેશા `min(id), max(id)` વડે lock કરો.
- **Short transactions.** locks ને શક્ય તેટલા ઓછા સમય માટે રાખો — validation, network calls, અને reads `BEGIN` **પહેલાં** કરો, પછી lock, write, અને `COMMIT` ઝડપથી. લાંબા transactions cycles અને lock waits માટે window પહોળી કરે છે.
- **જ્યાં safe હોય ત્યાં isolation ઘટાડો.** `SERIALIZABLE` વધુ/range locks લે છે અને વધુ deadlock કરે છે; `READ COMMITTED` (Postgres default) ઓછું lock કરે છે. correctness પૂરી કરે તેવું નબળામાં નબળું isolation વાપરો.
- **Deadlock પર Retry.** Deadlocks transient છે. deadlock error (Postgres `40P01`, MySQL `1213`) પકડો અને આખા transaction ને નાના backoff સાથે retry કરો. scale પર થોડું contention અનિવાર્ય છે, તેથી retry એ safety net છે, ordering નો વિકલ્પ નહીં.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર તપાસે છે કે તમે જાણો છો કે deadlocks **design વડે અટકાવાય છે, માત્ર પકડાતા નથી**. એકલા "retry" નું નામ આપવું નબળો જવાબ છે — great answer **consistent lock ordering** અને **short transactions** થી શરૂ કરે છે, પછી residual માટે retry ઉમેરે છે. સામાન્ય trap: ધારવું કે app એ deadlocks detect કરવા પડે; વ્યવહારમાં **DB cycle detect કરે છે અને victim ને abort કરે છે** તમારા માટે — તમારું કામ ordering વત્તા retry loop છે.

**Trade-offs:** access patterns dynamic હોય કે tables પર ફેલાય ત્યારે strict ordering મુશ્કેલ હોઈ શકે; નીચું isolation anomalies (non-repeatable reads) નું જોખમ છે જેના વિશે તમારે વિચારવું પડે. Retry loops **idempotent** અને capped હોવા જ જોઈએ, નહીંતર hot conflict retry storm માં ફેરવાય. Deadlock prevention ખરેખર lock-discipline વત્તા bounded retry છે, એક જ silver bullet નહીં.

તમારે તોડવો પડતો cycle

Strategies

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

સંબંધિત પ્રશ્નો