Yarış koşulları

Bir veritabanının tek bir terminalde yalıtılmış olarak nasıl çalıştığını anlamak basittir, ancak gerçek bir web senaryosunda istek gönderen yüzlerce eşzamanlı "Node/PHP/Go" işlemi olacaktır. Ünlü Yarış Koşullarının doğduğu yer burasıdır.

"Kayıp Güncelleme" sorunu

Kayıp Güncelleme, iki iş parçacığının aynı eski satırı okuduğunda, JavaScript sunucusunda bunun üzerinde biraz matematik yaptığında ve ardından sonucu kaydetmek için GÜNCELLEME'yi geri gönderdiğinde meydana gelir.

Senaryo:

• #5 ürününde 10 adet bulunmaktadır.
• A Kullanıcısı bir tane satın alır (Sunucu A "10"u okur, "9"u hesaplar).
• Aynı milisaniye içinde B kullanıcısı, A'nın satın alma işlemi COMMIT aşamasını tamamlamadan önce başka bir satın alır.
• Sunucu B ayrıca "10"u okur, "9"u hesaplar.
• A Sunucusu UPDATE: set quantity = 9 gönderir.
• B Sunucusu UPDATE: set quantity = 9 gönderir.
• Her ikisi de sayıyı başarılı bir şekilde azalttıklarını düşünüyor. Ancak nihai değerin 8 birim olması gerekirdi! Hayali bir satın alma işlemi kaybedildi.

Ağır işlemler gerektirmeyen çözüm (Atomik Güncellemeler)

Matematiği dışarıda okuyup yapmak yerine, DB'nin bunu her zaman senkronize olan güncelleme sırasında yapmasına izin verin.

-- Wrong
UPDATE products SET stock = 9 WHERE id = 5;

-- Correct and natively thread-safe
UPDATE products SET stock = stock - 1 WHERE id = 5;

Daha aşırı anormallikler (Kirli Okumalar ve Hayaletler)

• Kirli Okuma: Başka birinin henüz bir COMMIT tarafından onaylanmamış geçici verilerini okudunuz (ve aniden sizi geçersiz kılan ROLLBACK'e gidebilir).
• Hayalet Okumalar: Tüm satırları tararsınız, bu arada ikinci bir iş parçacığı yeni bir kayıt ekler, ardından aynı işlem sırasında başka bir tarama yaparsınız ve sihirli bir şekilde yeni kaydın birdenbire ortaya çıktığını ve hesaplanmış mali raporlardan ödün verdiğini görürsünüz.