Cevap

SQL'de işlemler, birkaç işlemi (insert/update/delete) tek bir atomik çalışma biriminde gruplandırmaya olanak tanır; bu birimi tamamen uygulayabilir veya iptal edebilirsiniz. İşlemin yaşam döngüsü şu komutlara dayanır:

• BEGIN veya START TRANSACTION — işlemin başlangıcı;
• COMMIT — değişikliklerin kaydedilmesi;
• ROLLBACK — işlem içindeki tüm değişikliklerin geri alınması.

SQL, paralel işlemler arasındaki veri görünürlüğünü tanımlayan ve "kirli okuma" veya "hayalet satırlar" gibi sorunlardan koruyan işlem yalnızlık seviyelerini (Read Uncommitted, Read Committed, Repeatable Read, Serializable) destekler.

Veri bütünlüğünü kontrol etmek için gerekenler:

• Yalnızlık seviyesinin seçimi (örneğin, bankacılık uygulamaları için — muhtemelen Serializable).
• Özellikle bir varlık aynı anda düzenlendiğinde işlem yönetiminin açık olması (örneğin, SELECT ... FOR UPDATE).

PostgreSQL'de bir örnek:

BEGIN;

-- Ürün satırını al ve kilitle
SELECT * FROM inventory WHERE id = 1 FOR UPDATE;

UPDATE inventory SET quantity = quantity - 1 WHERE id = 1;

COMMIT;

Kandırmaca Soru

Popüler DBMS'lerde (PostgreSQL, MySQL) varsayılan olarak hangi yalnızlık seviyeleri vardır ve SERIALIZABLE'dan nasıl farklıdır?

Cevap:
PostgreSQL'de varsayılan olarak Read Committed seviyeleri kullanılır — bunda işlem, sorgu anında yalnızca onaylanmış verileri görür, ancak "tekrar edilemeyen okumalar" (non-repeatable reads) mümkündür.
MySQL (InnoDB) için — Repeatable Read. Serializable ile farkı, yalnızca sonuncusu herhangi bir hayalet veya paralel değişiklikleri tamamen önler, ancak global kilitler nedeniyle belirgin şekilde daha yavaş çalışır.

Örnek:

-- Repeatable Read'te SELECT aynı satırları dönebilirken, Read Committed'de işlem içindeki iki SELECT arasında yeni satırlar ortaya çıkabilir.

---

Hikaye

Büyük bir finansal sistemde, düşük yalnızlık seviyesinde (Read Committed) toplu hesap transferleri sırasında aynı bakiyenin birden fazla işlem tarafından eşzamanlı olarak kullanıldığı durumlar ortaya çıktı. Bu durum, çift harcamalara (race condition) yol açtı. Serializable seviyesine geçtikten sonra ve kilit yönetimi düzgün yapıldığında sorun ortadan kalktı.

---

Hikaye

Elektronik ticarette, UPDATE product SET stock = stock - 1 ifadesinin bir işlem olarak sarmalanmaması, depodaki mevcuttan daha fazla ürün satışı ile sonuçlandı. Sorun, çok sayıda rekabetçi sipariş olduğunda belirlendi. Çözüm — işlemleri ve satır kilitlemesini SELECT ... FOR UPDATE ile kullanmak.

---

Hikaye

Lojistik sisteminde, bazı tablolarda sık güncellemeler sırasında açık bir commit yapılmadı. Hatalar durumunda, otomatik commit veya hatalı rollback nedeniyle bazı veriler kayboldu. Sonuç — kayıt kaybı ve maliyetli bir denetim.