एक transaction statements ना एका atomic unit मध्ये गटबद्ध करते: एकतर सर्व commit होतात किंवा सर्व roll back होतात, ज्याने ACID चे A, C, I, D मिळते. isolation level "I" ला tune करते — concurrent transactions एकमेकांचा uncommitted किंवा बदलणारा data किती पाहू शकतात.
| Level | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | शक्य | शक्य | शक्य |
| READ COMMITTED | नाही | शक्य | शक्य |
| REPEATABLE READ (InnoDB default) | नाही | नाही | बहुतांशी नाही* |
| SERIALIZABLE | नाही | नाही | नाही |
*InnoDB चे REPEATABLE READ MVCC (प्रत्येक transaction एक consistent snapshot वाचते) अधिक next-key locks वापरते, त्यामुळे ते बहुतेक phantoms देखील रोखते — SQL standard ज्याची मागणी करते त्यापेक्षा अधिक मजबूत.
SELECT @@transaction_isolation; -- REPEATABLE-READ by default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot taken here
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- both updates apply, or ROLLBACK undoes both
कारण नसेल तर InnoDB चा default (REPEATABLE READ) ठेवा. READ COMMITTED (जे Postgres/Oracle चे default आहे) high-write systems साठी lock contention कमी करते; SERIALIZABLE बरोबर आहे पण conflicting काम serialize करते आणि अधिक deadlock होऊ शकते.
Isolation हा correctness आणि concurrency यांच्यातील नियंत्रक (dial) आहे. या anomalies समजल्याने तुम्हाला "load खाली total जुळला नाही" सारखे bugs समजावता येतात आणि throughput विनाकारण न रोखता पैसे हलवणारे transactions बरोबर ठेवणारा level निवडता येतो.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या