Transaction isolation level'ları nelerdir? Hangi anomalileri önlerler?
Cevap
Isolation level, eşzamanlı transaction'ların birbirinin yaptığı değişiklikleri ne kadar görebileceğini belirler. Seviye arttıkça tutarlılık artar, eşzamanlılık performansı düşer.
Anomaliler
- Dirty read: henüz commit edilmemiş veriyi okumak.
- Non-repeatable read: aynı satırı iki kez okuyunca farklı değer görmek (arada başkası güncelledi).
- Phantom read: aynı koşulla iki sorguda farklı satır kümesi görmek (arada başkası satır ekledi).
- Serialization anomaly / write skew: her transaction tek başına geçerli, ama birlikte tutarsız sonuç (ör. iki doktor aynı anda nöbetten çıkar, kimse kalmaz).
Seviyeler (SQL standardı)
| Seviye | Dirty read | Non-repeatable | Phantom |
|---|---|---|---|
| Read Uncommitted | Olabilir | Olabilir | Olabilir |
| Read Committed | Önlenir | Olabilir | Olabilir |
| Repeatable Read | Önlenir | Önlenir | Olabilir |
| Serializable | Önlenir | Önlenir | Önlenir |
Gerçek veritabanlarındaki farklar
- PostgreSQL varsayılanı Read Committed'dir. MVCC kullanır, Read Uncommitted'i Read Committed gibi davranır. Repeatable Read'i snapshot isolation olduğu için phantom'ları da önler; Serializable seviyesi (SSI) çakışma tespit edince transaction'ı hata ile iptal eder.
- MySQL InnoDB varsayılanı Repeatable Read'dir; gap lock'larla phantom'ların çoğunu engeller.
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT COUNT(*) FROM nobetler WHERE gun = '2026-10-20';
UPDATE nobetler SET aktif = false WHERE doktor_id = 3;
COMMIT; -- çakışma varsa: could not serialize access... -> uygulama tekrar denerPratik çıkarım
Serializable veya Repeatable Read kullanıyorsanız uygulama tarafında retry mantığı zorunludur. Çoğu sistem Read Committed ile çalışır ve kritik noktalarda SELECT ... FOR UPDATE veya unique constraint gibi hedefli çözümler kullanır.
İlgili Veritabanı & SQL soruları
Bu konuda başka bir soru biliyor musun?
Mülakatta karşılaştığın soruları ekle, onaylandıktan sonra yayına alınsın.