RDBMS’lerde Optimistic Locking

Bu flood’da RDBMS’lerde ‘Optimistic Locking’den bahsedelim.

Önceki flood’da online bir oyunda kullanıcının sisteme iki kere giriş yapmasını engellemek için Read Committed izolasyonun işe yaramayacağını, Repetable Read veya Serializable kullanılması gerektiğini söyledik. Bir yandan da Repetable Read ve Serializable seviyelerinin eş zamanlı işlem kapasitesini azalttığı ve DB ölçeklenmesini engellediğine değindik.

Optimistic Locking ile uygulama seviyesinde uyulacak protokollerle daha düşük izolasyon seviyelerinde gerekli izolasyon sağlanabilir. Optimistic Locking genellikle tabloya eklenen ekstra bir kolon yardımıyla sağlanır. Bu kolonda ilgili kaydın (satırın) versiyonu (1, 2, vb) ya da kaydın son değiştirilme tarihi tutulur. Bu kayıtla ilgili yapılacak Update ve Delete işlemlerinde kayıttaki versiyon kolonu WHERE olarak eklenerek ilgili kaydın başka bir Transaction tarafından değiştirilip değiştirilmediği kontrolü yapılır ve izolasyon sağlanmış olur.

Online bir oyunda kullanıcının aynı anda bir kere sisteme giriş yapmasına izin verilmemesi gereken senaryoda versiyon kolonundaki değerin 2 olduğunu düşünelim. Güncelleme yaptığımız SQL cümlesinde UPDATE x SET a = true, version = 3 WHERE version = 2 yazıp sorgudan etkilenen kayıt sayısını kontrol edip, sayının 1 olduğu durumda girişe izin verip 0 olduğu durumda girişe izin vermezsek çift girişi engellemiş oluruz. Bu noktada Optimistic Locking’in bütün uygulama boyunca uyulması gereken bir kontrat olduğuna dikkat etmek gerekir. Uygulamanın herhangi bir yerinde versiyon kolonuna dikkat edilmeden yapılacak güncellemeler kontratı ve dolayısıyla da data tutarlılığını bozar.

Son olarak Optimistic Locking’in çok fazla çakışma olmayan senaryolarda kullanılması daha anlamlıdır. Çakışma olasılığı yüksek olan senaryolarda başarılı olan Transaction dışındaki Transaction’ların Rollback yapılması gerekir ki bu da daha fazla efora sahip olabilir.