İki AI ajanı aynı kaydı değiştirirken biri diğerini eziyor mu?

İki farklı niyet aynı eski kopyadan başlayabilir

İki AI ajanı aynı çalışma listesini okuyor. Listede yirmi kart kalmış. A ajanının görevi tamamlanan iki kartı düşmek, B ajanının görevi başka üç kartı düşmek. İkisi de yirmiyi okuyup yeni değer hazırlarsa A on sekiz, B on yedi yazar. Son kayıt on yedi olur; A’nın iki kartlık değişikliği kaybolur. Her çıkarma tek başına doğru olduğu halde birlikte yapılan güncelleme yanlıştır.

Bu uygulama sentetik bir kayıt ve yerel durum modeliyle sınırlıdır. Gerçek veritabanına kart güncellemesi gönderilmez. İki niyet farklı kart kümelerine aittir ve birer kez uygulanmasına izin verilmiştir. Kart sayısı bir stok, ödeme veya fiziksel üretim komutu değildir. Amaç aynı eski kopyayı okuyan iki farklı işlemin birbirinin sonucunu ezmesini görünür kılmaktır.

Buradaki sorun aynı isteğin iki kez gönderilmesi değildir. A ve B farklı iş niyetleri taşıyor. Tekilleştirme anahtarı her birinin tekrarını önleyebilir, fakat farklı iki isteğin aynı eski değerden hesaplanmasını tek başına çözmez. Kaynak temsilinin okunduğu andan yazılacağı ana kadar değişip değişmediğini de kontrol etmek gerekir.

Güncellemeyi okunan temsile bağlayın

If-Match, HTTP isteğini kaynak temsilinin belirtilen ETag ile eşleşmesine bağlar. MDN, güçlü karşılaştırma kullanıldığını ve eşleşmeyen koşulda 412 Precondition Failed yanıtı döndüğünü açıklar. Güncellemelerde bu mekanizma, kaynak okunduktan sonra başka bir değişikliğin ezilmesini önlemek için kullanılabilir. Burada sunucunun bu koşulu atomik biçimde uyguladığı açıkça varsayılır.Kaynak: MDN — If-Match header

B’nin 412 alması ikinci güncellemenin başarıyla yapıldığı anlamına gelmez. Kaynak on sekiz olarak kalır. B ancak güncel kaydı okuyup üç kart düşme niyetinin hâlâ geçerli olduğunu doğruladıktan sonra yeni taslak hazırlar. Yeni taslağın koşulu da yeniden okunan ETag olmalıdır. Okuma ile sonraki yazma arasında başka değişiklik olursa yeniden çatışma çıkabilir.

ETag değerleri istemci açısından sıralanacak sürüm sayıları değildir. v7, v8 ve v9 burada izi okumayı kolaylaştıran sentetik etiketlerdir. İstemci etiketin daha büyük veya daha yeni görünmesine bakmaz; sunucunun verdiği güçlü etiketi koşulda aynı biçimde kullanır. Her değişikliğin doğru temsil etiketiyle ilişkilendirilmesi sunucunun sözleşmesine aittir.

Yeni etiketi eski taslağa yapıştırmayın

Kaynak 20 kart ve güçlü ETag "v7". A iki, B farklı üç kartı düşecek; ikisi v7 okudu. A 18 yazar ve "v8" oluşur. B eski 17 taslağını If-Match "v7" ile gönderir. Sunucu karşılaştırma ve yazmayı atomik uygular. Her adımda kalan değeri, yanıtı ve izinli sonraki adımı yaz. 412 sonrası yalnız etiketi değiştirerek 17’yi tekrar gönderme. Güncel niyet hesabını göster; gerçek araca çağrı yapma.

Koşulsuz eski değer yazımı: son 17; A’nın değişikliği ezilir.
Koşullu yazım: A sonrasında 18; B’nin eski taslağı 412 ile uygulanmaz.
B güncel 18 üzerinden aynı geçerli niyeti yeniden hesaplar: 15. v8 koşulu hâlâ sağlanırsa son 15.
İki farklı niyetin toplam etkisi 2+3=5 karttır.

B 412 sonrasında yalnızca v8 etiketini alıp eski 17 gövdesini gönderirse ön koşul geçebilir; fakat niyet hâlâ yanlış miktara dönüşmüştür. On sekizden on yediye inmek üç değil bir kart düşer. Bu yüzden çatışma çözümü sadece yeni ETag edinmek değildir. Güncel veri üzerinde iş niyetinin yeniden değerlendirilmesini ve yeni sonucun hazırlanmasını gerektirir.

Aynı mantık bütün yazma işlerine otomatik uygulanamaz. Bazı değişiklikler yeni durumla birleştirilemeyebilir veya insan kararı gerektirebilir. Bu örnekte ayrı kart kümeleri ve değişmeyen düşme niyeti verilmiştir. Gerçek araç sözleşmesinde bu bilgi yoksa ajanın sayıları yeniden hesaplayıp işlem yapması doğru bir varsayım olmaz. Çatışma açık bir bekleme veya değerlendirme durumuna ayrılmalıdır.

Kontrol ile yazma tek karar olmalı

İstemci önce bir GET yapıp etiketi doğru bulabilir. Daha sonra koşulsuz yazarsa araya yine başka güncelleme girebilir. Sorunu çözen, okuma anındaki gözlem değil yazma anındaki atomik ön koşuldur. Sunucu karşılaştırmayı yapıp arada değişiklik kabul ettikten sonra eski gövdeyi yazıyorsa sözleşme korunmaz. Bu iki adımın birlikte uygulanması örneğin temel varsayımıdır.

• İş niyetini, okunan değeri ve ETag bilgisini ayrı saklayın.
• Yeni değeri hangi kaynak durumundan hesapladığınızı kaydedin.
• 412 yanıtını başarı veya sıradan bağlantı tekrarı saymayın.
• Yeniden okumadan ve niyeti değerlendirmeden yeni taslak göndermeyin.

If-Match yıldız değeri belirli bir sürümü eşlemek yerine kaynağın varlığına ilişkin bir koşuldur. Bu nedenle örnekteki eski temsil kontrolünün yerine kullanılamaz. Zayıf ETag değerleri de güçlü karşılaştırmada eşleşmez. Sunucunun sadece zayıf etiket sağlaması durumunda bu sözleşmenin çalıştığını varsaymayın; uygun koşullu güncelleme desteğini doğrulayın.Kaynak: MDN — If-Match header

Sürüm koşulu kullanıcının yetkisini veya işlemin onayını sağlamaz. Onay süresi dolmuşsa doğru ETag bir yazma izni oluşturmaz. Aynı şekilde işlem sonucu belirsiz bir bağlantı kesintisi varsa önceki etkinin durumu ayrıca değerlendirilir. Bu yazı yalnızca iki farklı niyetin eski kaynaktan yeni değer üretmesi sorununa odaklanır; diğer kabul koşulları korunur.

İkinci ajanın niyetini değiştirin

B ajanı bu kez üç yerine dört farklı kartı düşmek istesin. Başlangıç yine yirmi; A iki kartı düşüp on sekiz bırakmış olsun. B’nin eski yirmiden hazırladığı değerle güncel on sekizden hazırlaması gereken değeri karşılaştırın. Sonra eski taslağa yalnız yeni ETag eklenirse kaç kartlık etkinin gerçekleşeceğini hesaplayın.

B’nin eski taslağı 20−4=16; güncel niyet sonucu 18−4=14. Eski 16 taslağına yeni ETag eklemek 18’den 16’ya, yani yalnız 2 kartlık düşüş yapar. Doğru iki niyetin toplam etkisi 2+4=6; son kalan 14 olmalıdır. Koşul tekrar çatışırsa bu sonuç yazılmış sayılmaz.

Kendi araç tasarımınızda bir çatışmanın ardından neyin yeniden okunacağını ve neyin yeniden karara bağlanacağını yazın. Başarılı yanıt kadar uygulanmayan güncellemenin izini de görünür tutun. Böylece ajanın akıcı tamamlandı mesajı yerine gerçekten korunmuş iş niyetini değerlendirebilirsiniz.