ٹرانزیکشن آئسولیشن لیولز کیا ہیں؟

Question

Accepted Answer

**Isolation levels** یہ کنٹرول کرتے ہیں کہ بیک وقت چلنے والی ٹرانزیکشنز ایک دوسرے کی uncommitted (یا progress میں) تبدیلیوں میں سے کتنا دیکھ سکتی ہیں — **consistency** کو **performance/concurrency** کے خلاف trade کرتے ہوئے۔ زیادہ isolation زیادہ anomalies روکتا ہے لیکن locking/contention بڑھاتا ہے۔

## Concurrency anomalies (وہ چیزیں جو isolation روکتا ہے)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

یہ وہ مسائل ہیں جو تب واقع ہو سکتے ہیں جب ٹرانزیکشنز بیک وقت چلتی ہیں — isolation levels کنٹرول کرتے ہیں کہ کون سے روک دیے جاتے ہیں۔

## چار معیاری isolation levels

ہر اگلا level زیادہ anomalies روکتا ہے۔ **Read Committed** ایک عام ڈیفالٹ ہے (dirty reads روکتا ہے)؛ **Serializable** سب سے سخت ہے (ٹرانزیکشنز ایسے برتاؤ کرتی ہیں جیسے ایک وقت میں ایک چلتی ہیں) لیکن concurrency کے لیے سب سے محدود ہے۔

## Isolation level سیٹ کرنا

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## بنیادی trade-off

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## اہمیت کیوں ہے

ٹرانزیکشن isolation levels ڈیٹا بیسز میں **concurrency** کو سمجھنے کے لیے اہم advanced علم ہے — جب بیک وقت متعدد ٹرانزیکشنز چلتی ہیں (جیسے کسی بھی حقیقی multi-user application میں ہوتا ہے)، isolation levels ڈیٹا consistency اور performance کے درمیان trade-off کا تعین کرتے ہیں، اس لیے انہیں سمجھنا صحیح اور efficient concurrent applications بنانے کے لیے قیمتی ہے۔

بنیادی concepts یہ ہیں: **concurrency anomalies** (dirty reads، non-repeatable reads، phantom reads — وہ مسائل جو تب پیدا ہوتے ہیں جب ٹرانزیکشنز ایک دوسرے کی progress میں تبدیلیاں دیکھتی ہیں) اور کیسے **چار isolation levels** (Read Uncommitted، Read Committed، Repeatable Read، Serializable) بتدریج ان میں سے زیادہ کو روکتے ہیں۔

یہ سمجھنا صحیح کے لیے اہم ہے: بہت کم isolation level منتخب کرنا anomalies کی اجازت دے سکتا ہے جو ڈیٹا کو خراب کریں یا غلط نتائج دیں (مثال کے طور پر uncommitted ڈیٹا پڑھنا جو بعد میں rollback ہو جائے، یا inconsistent reads)، جبکہ بہت زیادہ concurrency کو کم کرتا ہے اور performance کو متاثر کرتا ہے۔

**بنیادی trade-off** — زیادہ isolation کا مطلب زیادہ صحیح ہے لیکن زیادہ locking/contention (کم concurrency، ممکنہ slowdowns اور deadlocks)، کم isolation کا مطلب زیادہ performance ہے لیکن anomalies کا خطرہ — یہ اہم سوچ ہے: آپ اسے ڈیٹا کی consistency کی ضروریات کی بنیاد پر منتخب کرتے ہیں (critical/financial ڈیٹا کو Serializable کی ضرورت ہو سکتی ہے؛ زیادہ تر applications ایک توازن کے طور پر Read Committed استعمال کرتے ہیں)۔

یہ جاننا کہ implementations مختلف ہوتے ہیں (MVCC بمقابلہ locking) بھی متعلقہ ہے۔

چونکہ concurrency حقیقی ڈیٹا بیس applications میں موروثی ہے، اور چونکہ isolation levels consistency اور performance کے درمیان critical توازن کو کنٹرول کرتے ہیں (غلط انتخاب یا تو ڈیٹا anomalies یا performance مسائل کا سبب بن سکتے ہیں)، isolation levels کو سمجھنا — anomalies، levels، اور consistency-vs-concurrency trade-off — صحیح اور efficient concurrent systems بنانے کے لیے قیمتی senior-level علم ہے اور ایک عام advanced انٹرویو موضوع ہے جو ڈیٹا بیس concurrency کی سمجھ کا مظاہرہ کرتا ہے۔