Transaction isolation levels क्या हैं?

Question

Accepted Answer

**Isolation levels** नियंत्रित करते हैं कि concurrent transactions एक-दूसरे के uncommitted (या in-progress) changes को कितना देख सकते हैं — **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)
```

ये वे समस्याएँ हैं जो तब हो सकती हैं जब transactions concurrently चलते हैं — isolation levels नियंत्रित करते हैं कि किन्हें रोका जाए।

## चार standard isolation levels

प्रत्येक उच्च level अधिक anomalies को रोकता है। **Read Committed** एक common default है (dirty reads को रोकता है); **Serializable** सबसे सख्त है (transactions ऐसे व्यवहार करते हैं जैसे एक बार में एक चल रहे हों) पर 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.).
```

## यह क्यों महत्वपूर्ण है

Transaction isolation levels **databases में concurrency** को समझने के लिए महत्वपूर्ण advanced ज्ञान हैं — जब कई transactions एक साथ चलते हैं (जैसा कि किसी भी real multi-user application में होता है), isolation levels data consistency और performance के बीच trade-off निर्धारित करते हैं, इसलिए इन्हें समझना correct, performant concurrent applications बनाने के लिए मूल्यवान है।

मुख्य concepts हैं **concurrency anomalies** (dirty reads, non-repeatable reads, phantom reads — वे समस्याएँ जो तब उत्पन्न होती हैं जब transactions एक-दूसरे के in-progress changes देखते हैं) और कैसे **चार isolation levels** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) उत्तरोत्तर उनमें से अधिक को रोकते हैं।

यह समझना correctness के लिए महत्वपूर्ण है: बहुत निम्न isolation level चुनना ऐसी anomalies की अनुमति दे सकता है जो data को corrupt करती हैं या गलत परिणाम देती हैं (जैसे uncommitted data पढ़ना जो बाद में roll back हो जाता है, या inconsistent reads), जबकि बहुत उच्च चुनना concurrency और performance को कम करता है।

**मौलिक trade-off** — उच्च isolation का अर्थ है अधिक correctness पर अधिक locking/contention (कम concurrency, संभावित slowdowns और deadlocks), निम्न isolation का अर्थ है अधिक performance पर anomalies का जोखिम — मुख्य अंतर्दृष्टि है: आप level को data की consistency आवश्यकताओं के आधार पर चुनते हैं (critical/financial data को Serializable की आवश्यकता हो सकती है; अधिकांश applications एक balance के रूप में Read Committed का उपयोग करते हैं)।

यह जानना कि implementations भिन्न होते हैं (MVCC बनाम locking) भी प्रासंगिक है।

चूंकि concurrency real database applications में अंतर्निहित है, और चूंकि isolation levels consistency और performance के बीच critical balance को नियंत्रित करते हैं (गलत विकल्पों के कारण या तो data anomalies या performance problems होती हैं), isolation levels को समझना — anomalies, levels, और consistency-बनाम-concurrency trade-off — correct, performant concurrent systems बनाने के लिए मूल्यवान senior-level ज्ञान है और एक common advanced interview topic जो database concurrency की समझ दर्शाता है।