Şeklen şöyle
SQL Server için şeklen şöyle
Veri tabanında yapılan değişikliğin bir başka işlem tarafından ezilmesi anlamına gelir. ACID veri tabanlarında Read Committed seviyesinde veya daha düşük transaction level kullanıldığında ortaya çıkar.
Lost Update Problemi Nedir?
Can multiple threads cause duplicate updates on constrained set? sorusunda açıklandığı gibi eğer iki thread aynı anda tek bir satırı güncellemeye çalışırsa kilidi ilk alan işlemi yaparken diğeri kilidin bırakılmasını bekler. Bekleyen thread kilidi alınca aranılan koşulun halen tutup tutmadığını tekrar değerlendirmelidir. Yoksa Lost Update problemi ortaya çıkar. Şeklen şöyleLost Update vs Read Skew
Örnek ver
Lost Update vs Write Skew
Örnek
Bir örnek şöyle
Case 3: Consider your team is on production support for a week. The requirement is at least 1 person should always be on support. Is it possible that if you and teammate try to unassign themselves (assuming the other one is still available) then no one is on support ?
Hatalı kod şöyle
## Psuedo codeif(totalMembersOnSupport() > 1) {removeFromSupport(user_id);}totalMembersOnSupport() -> Select count(user_id) from support where on_support = 't';removeFromSupport() -> update support set on_support = 'f' where user_id = '234';
Açıklaması şöyle. Yani her iki kullanıcı bir sayaca bakarak kendi satırlarına güncelleme yapıyorlar.
One difference between this case and the previously discussed cases is that in the previous cases concurrent transactions were trying to update the same row. But in this case, they are updating two different rows.This is known as Write Skew
Çözüm
1. Optimistic Concurrency kullanılabilir.
2. ACID seviyesini artırmak
- Repeatable Read yapmak gerekir ya da
- "Select For Update" yapmak gerekir ya da
- "Atomic işlem" yapmak gerekir ya da
- Veri tabanına kısıt koymak gerekir.
2.1 Select For Update
Select For Update yazısına taşıdım
3. Multi Version
Tüm veri eski tarihçesi ile saklanıyor. Client bir şekilde çözüm buluyor
Hiç yorum yok:
Yorum Gönder