İki doğru ön kontrol birlikte yanlış sonuç verebilir

İki ajan aynı demo oturumunda altı boş yer olduğunu görüyor. İkisinin de dörder kişilik ayrı bir isteği var. Her biri kendi hesabında dört yerin altı yere sığdığını doğruluyor. Fakat iki isteğin toplamı sekiz; mevcut kapasiteyi aşıyor. Sorun aritmetik veya aynı isteğin tekrarlanması değildir. Okuma ile yazma arasında ortak durum değişebildiği için işlem anındaki koşul korunmalıdır.

Bu yazıdaki oturum, istekler ve olay kayıtları sentetiktir. Gerçek rezervasyon yapılmaz. Amaç bir işlem sözleşmesi tasarlamak ve iki farklı sırada sonucunu hesaplamaktır. A ve B ayrı mantıksal isteklerdir; aynı işlemin yinelenen gönderimleri değildir. Aynı kimlikle tekrarı önleyen bir mekanizma bulunsa bile iki ayrı isteğin ortak kapasiteyi aşması ayrıca ele alınmalıdır.

AWS’nin iyimser kilitleme açıklaması, kayda sürüm eklemeyi ve güncelleme sırasında bu sürümü son okunan değerle karşılaştırmayı anlatır. Arada başka işlem değişiklik yaptıysa koşul başarısız olur. Bu yöntem çatışmayı yazma anında saptar. Aşağıdaki örnekte buna ayrıca kapasite yeterliliği kuralını ekliyoruz; yalnızca sürümün eşleşmesi istenen miktarın uygun olduğu anlamına gelmez.Kaynak: AWS — Optimistic locking with version number

İstekleri ve paylaşılan durumu ayrı gösterin

Sentetik başlangıç sözleşmesi
Ortak kayıt: OT-6 demo oturumu.
Başlangıç: boşYer=6, sürüm=7, ayrılanlar=[].
A isteği: 4 yer. B isteği: 4 yer. İki ayrı istek kimliği vardır.
Yetki ve gerekli insan onayı bu örnekte sağlanmış kabul edilir.
Başarılı işlem: kapasiteyi azaltma, istek kaydı ve sürüm artışı aynı tutarlı durum değişikliğinin parçalarıdır.
Koşul: okunan sürüm hâlâ aynı ve boş yer istenen miktara yeterli olmalı.
Bilerek kusurlu hazırlanmış zaman çizelgesi
AdımİşlemGörülen bilgiSorun
1A okur.6 boş yer, sürüm 7Henüz değişiklik yok.
2B okur.6 boş yer, sürüm 7A ile aynı eski görünüm.
3A dört yer ayırır.Kendi kontrolünde 4 ≤ 6Güncel durum diğer isteğe henüz okunmadı.
4B eski bilgiyle dört yer ayırır.Kendi kontrolünde 4 ≤ 6İki kabulün toplamı 8; kapasite 6.

Kusurlu uygulamada son kaydın nasıl bozulacağı yazma biçimine bağlıdır. İki istek ayrı ayrı kabul edilirken kalan yer yanlışlıkla iki görünebilir veya miktarlar kontrolsüz azaltılırsa negatif kapasite oluşabilir. Bu örneğin kanıtı belirli bir hata kodu değildir: kabul edilen iki isteğin toplamının sekiz olması altı kişilik sınırı ihlal eder. Durumun yalnızca son sayı alanını okumak kabul kayıtlarındaki sorunu gizleyebilir.

İnsan onayı da bu ayrımı ortadan kaldırmaz. Bir isteğin yapılmasına izin verilmiş olması, bütün diğer işlemler sırasında o kaynağın ayrılmış kaldığını göstermez. İş akışında gerçek bir ayırma adımı varsa onun da süresi, kapsamı ve değişiklik kuralları bulunmalıdır. Burada böyle bir ön ayırma yapılmadı; iki istek ortak kayıt üzerinde koşullu güncelleme anında karşılaştırılacaktır.

Kontrol ile yazmayı tek karar haline getirin

Elle hazırlanmış koşullu durum izi · A önce yazar
Adımİstenen koşulKararSon durum
A yazmasürüm=7 ve boşYer≥4Geçer; A dört yer alır.boşYer=2, sürüm=8, ayrılanlar=A:4
B eski yazmasürüm=7 ve boşYer≥4Kalır; sürüm artık 8.Durum değişmez.
B yeniden okumaGüncel kayıt okunur.2 boş yer görülür.B henüz yer almamıştır.
B yeniden değerlendirme2≥4 koşuluYetersiz kapasite; beklet.boşYer=2, sürüm=8

Koşulun uygulama ekranında kontrol edilip sonra ayrı bir yazma yapılması aynı korumayı sağlamaz. Araya yine başka işlem girebilir. İhtiyaç, güvenilir veri katmanının koşulu ve durum değişikliğini birlikte uygulamasıdır. Birden fazla kayıt güncellenecekse bunların tutarlılığı için uygun işlem sınırı ayrıca tasarlanmalıdır. Burada tek mantıksal kayıt içindeki kapasite ve ayırma listesi birlikte değişiyor varsayılmıştır.

B’nin başarısız koşulu, kullanıcı isteğinin silindiği veya iki kişiye düşürüldüğü anlamına gelmez. İstenen miktar hâlâ dörttür. Yeniden okuma sonrası iki yer kaldığı öğrenilir ve yeni bir karar gerekir. Ajan miktarı kendi başına azaltıp başarılı sonuç göstermemelidir. Kısmi karşılama desteklenecekse kullanıcı niyeti ve iş kuralı bunu açıkça tanımlamalıdır; bu örneğin sözleşmesinde böyle bir izin yoktur.

Sürüm numarasını yeniden okuyup hiçbir iş kuralına bakmadan yazmayı tekrar etmek de eksiktir. Yeni durum eski kararı değiştirmiş olabilir. Yeniden deneme hem teknik çatışmayı hem de güncel uygunluğu ele almalıdır. Çatışmalar sürekli sürüyorsa deneme sayısı ve bekletme yolu belirlenir; sınırsız tekrar, kapasiteyi veya adaleti kendiliğinden sağlamaz.

Başarıyı kalıcı durumla ilişkilendirin

Eşzamanlı istek inceleme istemi
Bağlam: OT-6 için A ve B ayrı ayrı dört yer istiyor. Girdi: altı boş yer, sürüm 7 ve iki olay çizelgesi. A’nın önce yazdığı durumda koşullu güncellemeyi adım adım hesapla. B’nin eski okumasını geçerli sayma; başarısız işlemde kapasiteyi değiştirme. Miktarı otomatik azaltma. Çıktı: durum tablosu, kabul edilen toplam, bekleyen istek ve yeniden değerlendirme koşulu. Kontrol: ayrılan yer + boş yer = 6; başarılı işlem sayısı ile sürüm artışı eşleşmeli.
Beklenen sonuç notu
A: dört yer ayrıldı. B: dört yer isteği karşılanmadı; iki boş yer kaldığı görüldü.
Kapasite kontrolü: 4 + 2 = 6.
Sürüm: 7 → 8; yalnızca A başarılı durum değişikliği yaptı.
B’nin başarısız yazma denemesi ve yeniden okuması kapasiteyi azaltmadı.
Gerçek oturum veya veri tabanı işlemi yapılmadı.
  1. İki olay aynı isteğin tekrarı mı, farklı istekler mi?
  2. Ortak kaynağın kimliği ve başlangıç durumu belli mi?
  3. Sürüm ve miktar koşulu yazma anında birlikte denetleniyor mu?
  4. Başarısız koşul bütün durum alanlarını değiştirmeden bırakıyor mu?
  5. Yeniden okuma sonrası iş kararı tekrar değerlendiriliyor mu?

Küçük alıştırma: B isteği başlangıçtan beri iki yer için verilmiş olsaydı ne olurdu? B’nin sürüm 7 ile ilk yazması yine çatışır. Güncel sürüm 8 ve iki boş yer okunduktan sonra iki kişilik istek koşulu sağlar. İkinci başarılı işlemle boş yer sıfır, sürüm 9 ve toplam ayrılan yer altı olur. Bu, dört kişilik isteği sessizce ikiye indirmekten farklı bir başlangıç durumudur.

A ile B’nin yazma sırasını ters çevirirseniz aynı kuralla B önce başarılı olabilir. Bu mekanizma hangi isteğin öncelikli olması gerektiğine karar vermez; yalnızca kapasite koşulunu korur. Öncelik veya adil sıra ihtiyacı varsa ayrıca tanımlanmalıdır. Tamamlanmış akış çiziminiz, izin, sıra ve güncel veri koşulunun hangi adımlarda ele alındığını açıkça göstermelidir.

Kaynaklar ve doğrulama

  • AWS — Optimistic locking with version number

    Okunan sürümü yazma anında koşulla karşılaştırma, uyuşmazlıkta reddetme ve güncel kaydı yeniden okuma. Kapasite ve rezervasyon örneği özgündür.

    Erişim ve kontrol:

İlgili okumalar

AI Ajanları ve İş Akışı Otomasyonu

AI Ajanları ve İş Akışı Otomasyonu programına ilişkin talebinizde, aynı kaynağı birden fazla kişinin veya sistemin değiştirdiği adımları belirtin. Eğitim uygulamasında bu adımları olay sırasıyla sınayabilirsiniz.

  • Kuruma özel planlanır