Aynı kaydı iki kullanıcı değiştirirse ne olur, nasıl önlenir

Aynı kaydı iki kullanıcı aynı anda açıp kaydederse, önlem alınmamışsa son kaydeden kişi diğerinin değişikliğini sessizce siler; buna kayıp güncelleme denir. Çözüm iki yoldan birindir: kayda bir sürüm alanı koyup kaydetme anında kontrol etmek ya da kritik işlemi veritabanı düzeyinde kilitlemek. Bu kararın önemi, hatanın hiçbir ekrana uyarı olarak düşmemesidir; kullanıcı kaydettiğini sanır, üç gün sonra tutarsız bir rakamla karşılaşır.

Kayıp güncelleme nasıl oluşur

Senaryo basittir. İki kullanıcı aynı sipariş kaydını açar. Birincisi adres alanını düzeltir ve kaydeder. İkincisi ekranı daha önce açtığı için elindeki kopya eski adresi taşır; o da not alanını doldurup kaydeder ve formun tamamını geri yazar. Birinci kullanıcının adres düzeltmesi kaybolur. Aynı durum stok, fiyat ve ödeme kaydında yaşandığında sonuç sadece can sıkıcı değil, parasaldır.

Sorunun kaynağı çoğu zaman şu alışkanlıktır: formun tüm alanları her kaydetmede tek seferde güncellenir. Yalnızca değişen alanı güncellemek riski azaltır ama tek başına yetmez, çünkü iki kullanıcı aynı alanı da değiştirebilir.

Riskin büyüklüğünü belirleyen şey kullanıcı sayısından çok ekranın açık kalma süresidir. Birkaç saniyede kapanan bir düzenleme penceresinde çakışma neredeyse hiç görülmez; yarım saat açık kalan, sekmeli ve uzun bir belge ekranında ise kaçınılmaz hale gelir. Bu yüzden önlem tartışması önce hangi ekranların uzun süre açık kaldığı sorusuyla başlar.

İyimser kilit: sürüm alanı ile çakışmayı yakalamak

İyimser kilit, kayıt üzerinde bir sürüm sayacı ya da son değişiklik zaman damgası tutar. Kullanıcı formu açarken bu değeri alır, kaydederken geri gönderir. Güncelleme komutu yalnızca sürüm hâlâ aynıysa yazar; değişmişse hiçbir satır etkilenmez ve yazılım çakışmayı anlar.

• Her tabloya bir sürüm alanı eklenir ve her güncellemede bir artırılır.
• Form, kaydı okurken sürümü gizli alanda taşır.
• Güncelleme koşulu kayıt kimliği ve sürümü birlikte içerir.
• Etkilenen satır sayısı sıfırsa kullanıcıya çakışma bildirilir.

Bu yöntem gündelik veri girişinin neredeyse tamamı için yeterlidir, ucuzdur ve kilit beklemesi yaratmaz. Tek koşulu, güncellemelerin tek bir yerden geçmesidir; farklı ekranların doğrudan tabloya yazması bu düzeni bozar.

Kötümser kilit ne zaman gerekir

Bazı işlemlerde çakışmayı sonradan fark etmek işe yaramaz; o anda engellemek gerekir. Stoktan düşüm, kasa hareketi, sıra numarası üretimi ve bakiye güncellemesi bu gruptadır. Burada ilgili satır işlem içinde kilitlenir, hesap yapılır, yazılır ve kilit bırakılır. Kilit süresi kısa tutulmalı, kilitli işlem içinde dış servis çağrısı yapılmamalıdır.

Çakışma anında kullanıcıya ne gösterilir

Teknik mesaj kullanıcıyı çaresiz bırakır. Doğru ekran üç şey söyler: kaydı başka bir kullanıcı sizden sonra değiştirdi, değişen alanlar şunlardır, şu seçeneklerden birini seçin. Seçenekler genellikle kendi değişikliğini yeniden uygulamak, karşı tarafın halini kabul etmek ya da alan bazında birleştirmektir.

• Değişen alanların eski ve yeni değerini yan yana göster.
• Kullanıcının yazdığı metni kaybetme; formda tut.
• Kritik alanlarda otomatik birleştirme yapma, kararı kullanıcıya bırak.
• Çakışmayı iz kaydına yaz; sık çakışan ekran bir süreç sorununun işaretidir.

Aynı ekranda sürekli çakışma yaşanıyorsa sorun genellikle teknik değildir: iki birim aynı kaydın aynı bölümünden sorumlu tutulmuştur. Bu durumda doğru çözüm daha akıllı bir birleştirme algoritması değil, alanların sahipliğini ayırmaktır; örneğin lojistik alanlarını yalnızca sevkiyat, fiyat alanlarını yalnızca satış düzenler.

Arka plan işleri de aynı kaydı yazar

Eş zamanlılık yalnızca iki kullanıcı arasında yaşanmaz. Entegrasyon servisleri, zamanlanmış işler ve webhook dinleyicileri de kullanıcıyla aynı anda aynı kaydı güncelleyebilir. Bir sipariş ekranda düzenlenirken kargo servisinden gelen bildirim durumu değiştirirse, kullanıcının kaydı bu değişikliği geri alabilir.

• Arka plan işleri tüm kaydı değil, yalnızca sorumlu olduğu alanları güncellesin.
• Kullanıcı formu, arka planın yönettiği alanları salt okunur göstersin.
• Dış kaynaklı güncellemeler de sürüm kontrolünden geçsin.
• Aynı kaydı işleyen iki ayrı iş aynı anda çalışmasın; iş başına kilit anahtarı kullanılsın.

Bu ayrım yapıldığında çakışma büyük ölçüde kendiliğinden biter, çünkü taraflar aynı alanlara değil farklı alanlara yazar.

Numara ve sayaç üretimi

Sipariş, teklif ve belge numarası üretimi eş zamanlılığın en sık kırıldığı yerdir. En büyük numarayı okuyup bir eklemek, iki kullanıcı aynı anda kaydettiğinde aynı numarayı iki kayda verir. Doğru çözüm, numarayı veritabanının kendi sıra üreteciyle almak ya da sayaç satırını işlem içinde kilitleyerek artırmaktır. Her durumda numara alanına benzersiz indeks koyulur; indeks, mantık hatasının veriye geçmesini engelleyen son bariyerdir.

Mükerrer kaydın entegrasyon tarafındaki karşılığı için idempotency anahtarı yazısı aynı mantığı dış servis çağrıları için anlatır.

Kısa kontrol listesi

• Düzenlenebilir her tabloda sürüm alanı var ve güncelleme koşulunda kullanılıyor.
• Stok, bakiye ve numara üretimi işlem içinde kilitle yapılıyor.
• Kilitli işlem içinde dış servis beklenmiyor.
• Çakışma kullanıcıya anlaşılır biçimde, alan karşılaştırmasıyla gösteriliyor.
• Benzersizlik yalnızca kodla değil, veritabanı indeksiyle de korunuyor.
• Çakışma olayları kayıt altına alınıyor ve düzenli gözden geçiriliyor.

Özet: eş zamanlılık bir ekran sorunu değil, veri modeli ve işlem sınırı sorunudur. KAV Yazılım çok kullanıcılı iş akışlarını bu kurallara göre kurar ve mevcut sistemlerde kayıp güncelleme riskini gözden geçirir.