Transaction isolation levels म्हणजे काय?

Question

Accepted Answer

**Isolation levels** नियंत्रित करतात की एकाचवेळी चलणारे (concurrent) transactions एकमेकांच्या uncommitted (किंवा in-progress) बदलांपैकी किती पाहू शकतात — **consistency** विरुद्ध **performance/concurrency** यांच्यात trade-off करतात. उच्च 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 एकाचवेळी चलत असताना येऊ शकतात — isolation levels नियंत्रित करतात कोणते प्रतिबंधित केले जातात.

## चार standard isolation levels

प्रत्येक उच्च level अधिक anomalies प्रतिबंधित करतो. **Read Committed** एक सामान्य 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 समजून घेण्यासाठी** महत्वाचे उन्नत ज्ञान आहे — जेव्हा अनेक transactions एकाचवेळी चलतात (कोणत्याही real multi-user application मध्ये असे होते), isolation levels data consistency आणि performance यांच्यामध्ये trade-off निर्धारित करतात, म्हणून सही, कार्यक्षम concurrent applications तयार करण्यासाठी या समजणे मूल्यवान आहे.

मूल संकल्पना आहेत **concurrency anomalies** (dirty reads, non-repeatable reads, phantom reads — या समस्या जी transactions एकमेकांच्या in-progress बदल पाहतात तेव्हा उद्भवतात) आणि **चार isolation levels** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) कसे progressively अधिक anomalies प्रतिबंधित करतात.

हे समजणे शुद्धता साठी महत्वाचे आहे: खूपच कमी isolation level निवडल्यास data corrupt होणारे किंवा चुकीचे परिणाम देणारे anomalies येऊ शकतात (उदा. uncommitted data वाचणे जे नंतर rollback होते, किंवा inconsistent reads), तर खूपच उच्च निवडल्यास concurrency आणि performance कमी होते.

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

ते माहित असणे की implementations भिन्न आहेत (MVCC विरुद्ध locking) हेही relevant आहे.

Concurrency real database applications मध्ये अंतर्निहित असल्यामुळे, आणि isolation levels consistency आणि performance यांच्यामधील महत्वाचा balance नियंत्रित करतात (चुकीच्या निवडीमुळे एकतर data anomalies किंवा performance समस्या येतात), isolation levels — anomalies, levels, आणि consistency-vs-concurrency trade-off — हे समजणे सही, कार्यक्षम concurrent systems तयार करण्यासाठी आणि सामान्य उन्नत interview topic म्हणून database concurrency समजून घेणारे senior-level ज्ञान आहे.