Deadlock کیا ہے اور آپ اسے کیسے روکتے ہیں؟

Question

Accepted Answer

ایک **deadlock** اس وقت واقع ہوتا ہے جب دو (یا زیادہ) transactions میں سے ہر ایک کے پاس وہ lock ہو جسے دوسرا چاہتا ہے، تو کوئی بھی آگے نہیں بڑھ سکتا — وہ ایک دوسرے کے انتظار میں ہمیشہ کے لیے پھنسے رہتے ہیں۔ Databases deadlocks کو detect کرتے ہیں اور انہیں **ایک transaction کو abort کر کے** حل کرتے ہیں ("victim")، جسے دوبارہ کوشش کرنی ہوگی۔ وقتی عمل کی applications کے لیے causes اور prevention کو سمجھنا ضروری ہے۔

## Deadlock کیسے ہوتا ہے

```text
Transaction A: locks row 1, then wants row 2
Transaction B: locks row 2, then wants row 1
→ A waits for B (to release row 2), B waits for A (to release row 1) → DEADLOCK
  Neither can proceed; they're waiting on each other in a cycle.
```

```sql
-- Transaction A                    -- Transaction B (concurrent)
BEGIN;                              BEGIN;
UPDATE accounts SET .. WHERE id=1;  UPDATE accounts SET .. WHERE id=2;  -- each locks a row
UPDATE accounts SET .. WHERE id=2;  UPDATE accounts SET .. WHERE id=1;  -- each wants the OTHER's
-- → DEADLOCK: the database aborts one transaction
```

## Databases deadlocks کو کیسے handle کرتے ہیں

```text
Databases DETECT deadlocks (find the cycle of waiting transactions) and resolve them
by ABORTING one transaction (the victim) with a deadlock error → it must RETRY.
→ Your application must handle the deadlock error and retry the transaction.
```

## روک تھام کی حکمت عملی

```text
✓ CONSISTENT LOCK ORDERING — always acquire locks in the SAME order (e.g. always
  lock the lower account id first). This breaks the cycle → the #1 prevention technique.
✓ Keep transactions SHORT — hold locks for less time (less chance to overlap)
✓ Access tables/rows in a consistent order across all transactions
✓ Use lower isolation levels where appropriate (less locking)
✓ Avoid user interaction / long operations inside a transaction (holds locks too long)
✓ Handle deadlock errors with RETRY logic (deadlocks can't be fully eliminated)
```

**#1 روک تھام** ہے **مستقل lock ordering**: اگر تمام transactions locks کو ایک جیسی ترتیب میں حاصل کریں (مثال کے طور پر ہمیشہ کم id پہلے)، تو سرکلر انتظار نہیں بن سکتا۔

## دوبارہ کوشش کا نمونہ

```text
Since deadlocks can still happen, applications should catch the deadlock error and
RETRY the transaction (often a few times with a small delay). This is standard
resilience for concurrent database code.
```

## اس کی اہمیت

Deadlocks ایک اہم concurrency مسئلہ ہیں databases میں — یہ کسی بھی application میں پیش آتے ہیں جہاں بیک وقت transactions ہوتی ہوں جو overlapping ڈیٹا میں تبدیلی کرتی ہوں، اور انہیں سمجھنا مضبوط وقتی نظام بنانے کے لیے سینیئر سطح کا قیمتی علم ہے۔

**Cause** کو سمجھنا — دو transactions میں سے ہر ایک کے پاس وہ lock ہے جسے دوسرے کو چاہیے، جو ایک سرکلر انتظار بناتا ہے جہاں کوئی بھی آگے نہیں بڑھ سکتا — یہ بنیاد ہے۔

جاننا کہ databases deadlocks کو **کیسے handle** کرتے ہیں (cycle کو detect کرنا اور ایک transaction کو victim کے طور پر abort کرنا، جسے دوبارہ کوشش کرنی ہوگی) اہم ہے کیونکہ اس کا مطلب ہے کہ آپ کی **application کو deadlock errors کو retry logic کے ساتھ handle کرنا ہوگا** — deadlocks کو مکمل طور پر ختم نہیں کیا جا سکتا، تو resilient وقتی code deadlock error کو catch کرتا ہے اور دوبارہ کوشش کرتا ہے (ایک معیاری، اہم نمونہ)۔

**روک تھام کی حکمت عملی** اہم عملی علم ہے، خاص طور پر #1 تکنیک: **مستقل lock ordering** (تمام transactions میں ہمیشہ locks کو ایک جیسی ترتیب میں حاصل کرنا، جو سرکلر-انتظار کی حالت کو توڑتا ہے جو deadlocks کا سبب بنتا ہے) — ساتھ ہی transactions کو مختصر رکھنا (locks کو کم دیر تک رکھنا)، resources کو مستقل ترتیب میں access کرنا، اور transactions کے اندر لمبی operations سے بچنا۔

چونکہ deadlocks حقیقی مسائل کا سبب بنتے ہیں (ناکام transactions، errors، کمزور کارکردگی) وقتی database applications میں، اور چونکہ ان کے cause (سرکلر lock انتظار)، روک تھام (خاص طور پر مستقل lock ordering اور مختصر transactions)، اور retry logic کی ضرورت کو سمجھنا وہی ہے جو آپ کو مضبوط وقتی نظام بنانے دیتا ہے، deadlocks کو سمجھنا کسی بھی application کے لیے سینیئر سطح کا قیمتی علم ہے جہاں اہم وقتی database access ہو — ایک بار بار متعلقہ operational فکر اور ایک عام اعلیٰ interview موضوع جو database concurrency اور resilience کی سمجھ کا مظہر ہے۔