हज़ारों concurrent transactions के साथ आप deadlocks कैसे रोकते हैं?

Question

IT Interview Practice · Accepted Answer

**locks को एक consistent global order में acquire करें, transactions छोटे रखें, जहां safe हो वहां isolation कम करें, और जब deadlock फिर भी हो तो हारने वाले को 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 है। एक क्लासिक 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 करें, लिखें, और तेज़ `COMMIT` करें। लंबे transactions cycles और lock waits की window चौड़ी करते हैं।
- **जहां safe हो isolation कम करें.** `SERIALIZABLE` अधिक/range locks लेता है और अधिक deadlock करता है; `READ COMMITTED` (Postgres default) कम lock करता है। सबसे कमज़ोर isolation इस्तेमाल करें जो अब भी correctness पूरी करे।
- **Deadlock पर retry.** Deadlocks transient हैं। deadlock error (Postgres `40P01`, MySQL `1213`) catch करें और पूरे transaction को छोटे backoff के साथ retry करें। scale पर कुछ contention अपरिहार्य है, इसलिए retry एक safety net है, ordering का विकल्प नहीं।

## इंटरव्यू का नज़रिया

Interviewer परखता है कि क्या आप जानते हैं deadlocks **design से रोके जाते हैं, केवल catch नहीं**। अकेले "retry" नाम लेना एक कमज़ोर जवाब है — बढ़िया जवाब **consistent lock ordering** और **short transactions** से शुरू होता है, फिर अवशेष के लिए retry जोड़ता है। एक आम जाल: मानना कि app को deadlocks detect करने होंगे; व्यवहार में **DB cycle detect करता है और एक victim abort करता है** आपके लिए — आपका काम ordering plus एक retry loop है।

**ट्रेड-ऑफ़:** सख्त ordering कठिन हो सकता है जब access patterns dynamic हों या tables में फैलें; कम isolation anomalies (non-repeatable reads) का जोखिम है जिनके बारे में आपको सोचना होगा। Retry loops **idempotent** और capped होने चाहिए, वरना एक hot conflict एक retry storm बन जाता है। Deadlock prevention वास्तव में lock-discipline plus एक bounded retry है, एक अकेली silver bullet नहीं।

वह cycle जिसे आपको तोड़ना है

Strategies

इंटरव्यू का नज़रिया

संबंधित प्रश्न