हजारो concurrent transactions सह deadlocks तुम्ही कसे टाळाल?

Question

IT Interview Practice · Accepted Answer

**locks एका सुसंगत global order मध्ये acquire करा, transactions लहान ठेवा, सुरक्षित असेल तिथे 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 आहे. एक classic bug: एक money transfer जो accounts `(from, to)` order मध्ये lock करतो तो उलट transfer सोबत deadlock करतो; नेहमी `min(id), max(id)` ने lock करा.
- **Short transactions.** locks शक्य तितका कमी वेळ धरा — validation, network calls, आणि reads `BEGIN` **आधी** करा, नंतर lock, write, आणि जलद `COMMIT` करा. Long transactions cycles आणि lock waits साठी window रुंद करतात.
- **सुरक्षित असेल तिथे 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" नावाने सांगणे एक कमकुवत उत्तर आहे — उत्तम उत्तर **consistent lock ordering** आणि **short transactions** ने सुरू होते, नंतर उरलेल्यासाठी retry जोडते. एक सामान्य सापळा: app ने deadlocks detect केले पाहिजेत असे गृहीत धरणे; प्रत्यक्षात **DB cycle detect करते आणि एका victim ला abort करते** तुमच्यासाठी — तुमचे काम म्हणजे ordering अधिक एक retry loop.

**तडजोडी:** access patterns dynamic असतील किंवा tables पसरत असतील तेव्हा strict ordering कठीण असू शकते; कमी isolation anomalies (non-repeatable reads) चा धोका देते ज्यांचे तुम्हाला reasoning करावे लागते. Retry loops **idempotent** आणि capped असले पाहिजेत, अन्यथा एक hot conflict एका retry storm मध्ये बदलतो. Deadlock prevention खरोखर lock-discipline अधिक एक bounded retry आहे, एक single silver bullet नाही.

तुम्हाला तोडायचा cycle

strategies

मुलाखतीचा दृष्टिकोन

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