Veritabanı Transaction Nedir? ACID, MVCC ve İzolasyon Seviyeleri (2026 Rehberi)
Transaction, veritabanında birlikte başarılı olmak (Commit) veya herhangi bir hatada tamamen iptal edilmek (Rollback) zorunda olan mantıksal bir işlem dizisidir. Amacı, sistem çökmeleri veya eşzamanlı erişimler sırasında veri bütünlüğünü korumaktır. Bu yapı, ACID (Atomicity, Consistency, Isolation, Durability) adı verilen dört temel kural ile güvence altına alınır.
Yüksek trafikli bir sistemde veritabanı transaction yönetimi, veri bütünlüğünü korurken performansı yüksek tutmanın temel anahtarıdır. Transaction mekanizması olmadan banka havalesi, sipariş oluşturma veya stok düşme gibi kritik senaryolarda veri tutarsızlıkları (data corruption) yaşanması kaçınılmazdır.
Bu kapsamlı rehberde ACID özelliklerini, İzolasyon Seviyesi (Isolation Level) çeşitlerini, 2PL (Two-Phase Locking) ile MVCC (Multi-Version Concurrency Control) farklarını ve uygulamanızda kullanmanız gereken Optimistic / Pessimistic Locking stratejilerini PostgreSQL, MySQL ve Oracle bağlamında detaylıca inceliyoruz.
1. ACID Nedir? Transaction'ların 4 Temel Özelliği
Veritabanlarının hatalar, çökmeler veya aynı anda gelen binlerce istek karşısında bile veriyi doğru şekilde işleyebilmesi için ACID prensiplerine uyması gerekir.
Atomicity (Bölünmezlik)
Atomicity, transaction içindeki işlemlerin bir bütün olarak ele alınmasını sağlar: Ya tüm işlemler başarılı olur (Commit) ya da hepsi iptal edilip geri alınır (Rollback). Örneğin, A hesabından B hesabına para transferi yapılırken ilk adım gerçekleşip ikinci adımda sunucu çökerse, undo log sayesinde A hesabından düşülen bakiye geri yüklenir.
Consistency (Tutarlılık)
Consistency, transaction bittiğinde veritabanının geçerli bir durumdan yine geçerli bir duruma geçmiş olmasını garanti eder. Veritabanındaki tüm kısıtlamalar (Primary Key, Foreign Key, NOT NULL, CHECK vb.) işlem öncesinde ve sonrasında ihlal edilmemelidir.
Isolation (Yalıtım)
Isolation, aynı anda (eşzamanlı) çalışan transaction'ların birbirini nasıl etkilediğini tanımlar. İdeal senaryoda tüm işlemler sırayla (Serializable) çalışıyormuş gibi davranmalıdır. Ancak bu durum performansı çok düşürdüğü için veritabanları farklı İzolasyon Seviyeleri (Isolation Levels) sunarak hız ve tutarlılık arasında denge kurmanızı sağlar.
Durability (Kalıcılık)
Durability, başarılı (commit edilmiş) bir transaction'ın, sistemin fişi çekilse bile asla kaybolmamasını sağlar. Veritabanları bunu sağlamak için veriyi diske kalıcı olarak yazmadan önce WAL (Write-Ahead Log) veya Redo Log adı verilen özel log dosyalarına kaydeder.
2. Eşzamanlılık Kontrolü: 2PL ve MVCC
Aynı veriye aynı anda erişmeye çalışan transaction'ları yönetmek için iki temel mimari kullanılır:
Two-Phase Locking (2PL - İki Aşamalı Kilitleme)
Transaction'ların kilit (lock) kullanarak sırayla ilerlemesini sağlar. İki aşaması vardır: Genişleme fazında (işlem yaparken) tüm kilitler alınır, daralma fazında (işlem bitince) tüm kilitler bırakılır. 2PL veri tutarlılığını kesin olarak sağlasa da, kilit beklemeleri (blocking) ve Deadlock (Ölümcül Kilitlenme) riskini artırır.
Multi-Version Concurrency Control (MVCC)
MVCC, "okuyanlar yazanları, yazanlar da okuyanları bekletmesin" felsefesiyle çalışır. Satırları kilitlemek yerine, her satırın farklı zamanlara ait "versiyonlarını" (snapshot) tutar. Böylece bir işlem veriyi güncellerken, diğer bir işlem verinin eski (commit edilmiş) versiyonunu kilitlenmeden okuyabilir. Oracle ve PostgreSQL bu yapıyı çok yoğun kullanır.
3. Transaction Anomalileri (Okuma Hataları)
Veritabanında izolasyon seviyesi düştükçe aşağıdaki anomaliler (tutarsızlıklar) ortaya çıkabilir:
- Dirty Read (Kirli Okuma): Bir transaction'ın, başka bir transaction tarafından değiştirilmiş ama henüz commit edilmemiş (onaylanmamış) veriyi okumasıdır.
- Non-repeatable Read: Bir transaction içinde aynı satırın iki kez okunduğunda, araya giren başka bir işlemin o satırı güncellemesi yüzünden farklı değerler alınmasıdır.
- Phantom Read (Hayalet Okuma): Bir sorgu (örneğin
SELECT COUNT(*)) iki kez çalıştırıldığında, araya giren başka bir işlemin yeni satırlar (insert) eklemesi nedeniyle sonuç kümesinin değişmesidir. - Lost Update (Kayıp Güncelleme): İki farklı transaction aynı anda aynı veriyi okuyup güncellediğinde, son yazanın ilk yazanın verisini ezmesi ve verinin geri döndürülemez şekilde kaybolmasıdır.
4. İzolasyon Seviyeleri (Isolation Levels) Karşılaştırması
| İzolasyon Seviyesi | Dirty Read | Non-Repeatable Read | Phantom Read |
|---|---|---|---|
| Read Uncommitted | Oluşabilir | Oluşabilir | Oluşabilir |
| Read Committed (Oracle/PostgreSQL Varsayılanı) | Engellenir | Oluşabilir | Oluşabilir |
| Repeatable Read (MySQL Varsayılanı) | Engellenir | Engellenir | Oluşabilir |
| Serializable | Engellenir | Engellenir | Engellenir |
5. Durability ve Transaction Log (WAL) Mimarisi
Veritabanları, her değişikliği anında diske yazmak yerine, performans için değişiklikleri bellekte (RAM) yapar. Ancak verilerin kaybolmamasını sağlamak için, commit edilen her işlemi diske sıralı olarak yazılan WAL (Write-Ahead Log) veya Redo Log dosyasına kaydeder (fsync ile). Sistem çökerse, yeniden başlatıldığında bu log dosyasındaki işlemler ileriye doğru (redo) tekrar oynatılarak veri kurtarılır.
6. Dağıtık Transaction'lar ve JTA (2PC)
Eğer bir işlem birden fazla veritabanını veya bir veritabanı ile bir mesaj kuyruğunu (örn. RabbitMQ) aynı anda güncelliyorsa, buna Dağıtık Transaction (Distributed Transaction) denir. Java dünyasında bu süreç JTA (Java Transaction API) ve Two-Phase Commit (2PC - İki Aşamalı Onay) protokolü ile yönetilir:
- Prepare Fazı: Transaction yöneticisi tüm kaynaklara "Commit için hazır mısın?" diye sorar.
- Commit Fazı: Eğer tüm kaynaklar "Hazırım" derse işlem onaylanır. Tek bir kaynak bile hata verirse tüm sistem Rollback edilir.
7. Optimistic ve Pessimistic Locking Stratejileri
Web uygulamalarında veritabanı transaction'larını kullanıcının ekran başında beklediği süre boyunca açık tutmak (kilitleri bırakmamak) sistemin kilitlenmesine yol açar. Bu yüzden uygulama (kod) seviyesinde iki farklı kilitleme (locking) stratejisi uygulanır:
Pessimistic Locking (Kötümser Kilitleme)
Çakışmanın (conflict) kesinlikle olacağını varsayar. Veriyi okurken doğrudan veritabanı seviyesinde özel bir kilit alır (Örn: SELECT ... FOR UPDATE). Diğer işlemler bu kilit bırakılana kadar beklemek zorundadır. Lost Update'i kesin önler ama Deadlock riskini artırır.
Optimistic Locking (İyimser Kilitleme)
Çakışmanın nadir olacağını varsayar. Veritabanı seviyesinde kilit koymaz, bunun yerine tabloya bir version kolonu ekler.
- Veri okunurken versiyonu alınır (Örn:
version = 1). - Kullanıcı veriyi günceller ve kaydet tuşuna basar.
- Sistem arka planda şu sorguyu atar:
UPDATE table SET veri=?, version=2 WHERE id=? AND version=1 - Eğer başka bir kullanıcı o sırada veriyi değiştirmişse versiyon 2 olmuştur. Yukarıdaki sorgu hiçbir satırı güncelleyemez (0 döner). Sistem bir OptimisticLockException fırlatır ve kullanıcının başkasının verisini ezmesini (Lost Update) engeller.
8. Yüksek Performans İçin Best Practices
- Transaction'ları Mümkün Olduğunca Kısa Tutun: Uzun süren HTTP istekleri veya 3. parti API çağrıları sırasında transaction'ı açık bırakmayın.
- Web Uygulamalarında Optimistic Locking Kullanın: Lost update problemini önlemek için veritabanını kilitlemek yerine versiyon (version) mantığını tercih edin.
- Read-Only Transaction'ları Ayırın: Sadece veri okuyacağınız yerlerde (Örn: Spring'de
@Transactional(readOnly = true)) read-only flag'ini kullanın. Bu, veritabanının gereksiz kilit ve log işlemlerinden kaçınarak performans artışı sağlamasına olanak tanır. - İzolasyon Seviyenizi İyi Tanıyın: Kullandığınız veritabanının (MySQL, PostgreSQL vb.) varsayılan izolasyon seviyesini ve hangi anomalilere (Phantom Read vb.) izin verdiğini kesinlikle öğrenin.