آپ ہزاروں concurrent transactions کے ساتھ deadlocks کیسے روکتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**locks کو ایک مستقل global ترتیب میں حاصل کریں، 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)
```

## حکمتِ عملیاں

- **مستقل lock ordering۔** اگر ہر transaction ہمیشہ rows کو ایک ہی ترتیب میں lock کرے (مثلاً چڑھتی primary key)، تو ایک cycle ناممکن ہے — A اور B دونوں پہلے row 1 پکڑتے ہیں، لہٰذا ایک بس انتظار کرتا ہے۔ یہ سب سے بڑا lever ہے۔ ایک کلاسک bug: ایک money transfer جو accounts کو `(from, to)` ترتیب میں lock کرتا ہے وہ الٹے transfer کے ساتھ deadlock کرتا ہے؛ ہمیشہ `min(id), max(id)` سے lock کریں۔
- **مختصر transactions۔** locks کو جتنا کم ممکن ہو رکھیں — validation، network calls، اور reads `BEGIN` سے **پہلے** کریں، پھر lock کریں، لکھیں، اور تیزی سے `COMMIT` کریں۔ طویل transactions cycles اور lock waits کے لیے window چوڑی کرتی ہیں۔
- **جہاں محفوظ ہو isolation کم کریں۔** `SERIALIZABLE` زیادہ/range locks لیتا ہے اور زیادہ deadlock کرتا ہے؛ `READ COMMITTED` (Postgres default) کم lock کرتا ہے۔ کمزور ترین isolation استعمال کریں جو پھر بھی درستگی پوری کرے۔
- **Deadlock پر retry۔** Deadlocks عارضی ہیں۔ deadlock error پکڑیں (Postgres `40P01`، MySQL `1213`) اور پورے transaction کو ایک چھوٹے backoff کے ساتھ retry کریں۔ کچھ contention scale پر ناگزیر ہے، لہٰذا retry ایک safety net ہے، ordering کا متبادل نہیں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ کیا آپ جانتے ہیں کہ deadlocks **ڈیزائن سے روکے جاتے ہیں، صرف پکڑے نہیں جاتے**۔ صرف "retry" کا نام لینا ایک کمزور جواب ہے — عمدہ جواب **مستقل lock ordering** اور **مختصر transactions** سے شروع ہوتا ہے، پھر باقی ماندہ کے لیے retry شامل کرتا ہے۔ ایک عام جال: فرض کرنا کہ app کو deadlocks detect کرنے ہوں گے؛ عملی طور پر **DB cycle detect کرتا ہے اور ایک victim abort کرتا ہے** آپ کے لیے — آپ کا کام ordering جمع ایک retry loop ہے۔

**توازن:** سخت ordering مشکل ہو سکتی ہے جب access patterns متحرک ہوں یا tables پر پھیلے ہوں؛ کم isolation anomalies (non-repeatable reads) کا خطرہ رکھتا ہے جن پر آپ کو استدلال کرنا ہوگا۔ Retry loops کو **idempotent** اور محدود ہونا چاہیے، ورنہ ایک hot conflict ایک retry storm میں بدل جاتا ہے۔ Deadlock prevention دراصل lock-discipline جمع ایک محدود retry ہے، کوئی واحد silver bullet نہیں۔

وہ cycle جو آپ کو توڑنا ہے

حکمتِ عملیاں

انٹرویو کا نقطۂ نظر

متعلقہ سوالات