transaction statements ને એક atomic unit માં જૂથબદ્ધ કરે છે: કાં તો બધું commit થાય કાં તો બધું roll back — ACID ના A, C, I, D આપતાં. isolation level "I" ને tune કરે છે — સમાંતર transactions એકબીજાના uncommitted કે બદલાતાં ડેટા વિશે કેટલું જોઈ શકે.
transaction statements ને એક atomic unit માં જૂથબદ્ધ કરે છે: કાં તો બધું commit થાય કાં તો બધું roll back — ACID ના A, C, I, D આપતાં. isolation level "I" ને tune કરે છે — સમાંતર transactions એકબીજાના uncommitted કે બદલાતાં ડેટા વિશે કેટલું જોઈ શકે.
| 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 ને પણ block કરે છે — 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 સમજાવી શકો છો અને એવો level પસંદ કરી શકો છો જે throughput ને બિનજરૂરી રીતે ગૂંગળાવ્યા વગર money-moving transactions ને સાચાં રાખે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો