Bir kullanıcı tarafından düzenlenirken bulut DB'mdeki satırları kilitlemeli miyim


12

Buluttaki verilere devam eden bir masaüstü uygulaması oluşturuyorum. Bir endişem var uygulamada bir öğeyi düzenlemek ve bir süre veri bayat neden bırakarak bir başlangıçtır. Bu, 2 kişinin aynı öğeyi aynı anda düzenlemeye çalışması durumunda da görülebilir. Düzenlemelerini tamamladıklarında ve verileri kaydetmek istediklerinde, veritabanında şu anda mevcut olanların üzerine yazmam veya son değişiklikten sonra düzenlemeye başladıklarını kontrol etmeliyim ve ya değişikliklerini atmaya zorlayabilirler ya da belki de risk alma seçeneği sunabilirler. başkasının değişikliklerinin üzerine yazmak.

Bir alan ekleme is_lockedve lock_timestampDB tablo düşündüm . Kullanıcı öğeyi düzenlemeye başladığında satır is_lockedtrue olarak değişir ve kilit zaman damgasını geçerli saate ayarlar. Daha sonra kilidin tutulduğu bir miktar zamanım olurdu (ör. 5 dakika). Başka bir kişi öğeyi düzenlemeye çalışırsa, öğenin kilitli olduğunu ve kilidin otomatik olarak sona erdiğini belirten bir mesaj alır. Kullanıcı düzenleme sırasında uzaklaşırsa, kilit göreceli olarak kısa bir süre sonra otomatik olarak sona erer ve bunu yaptıktan sonra kullanıcı, kilidin süresinin dolduğu konusunda uyarılır ve veriler yenilendikten sonra düzenlemeyi yeniden başlatmak zorunda kalır.

Bu, eski verilerin üzerine yazılmasını önlemek için iyi bir yöntem olabilir mi? Aşırı mı (uygulamanın birden fazla kişi tarafından aynı anda tek bir hesapta kullanılmasını beklemiyorum).

(Sahip olduğum bir diğer endişe, aynı kişi için bir kilit elde eden 2 kişi, ancak bunun rahat olduğum bir yarış durumu olduğuna inanıyorum.)


1
"Sahip olduğum başka bir endişe aynı kişi için bir kilit almak 2 kişi, ancak ben rahat bir yarış durumu olduğuna inanıyorum" - kilit satın alma etrafında bir veritabanı işlemi kullanarak bu tür yarış koşullarını önlemek gerekir.
Jules

Çoğu veritabanı motoru (en azından ilişkisel türden) bunun için destek sağlamıştır. RDBMS dünyasında çok yaygın bir kavramdır ve "oyuncak" veritabanları bile iyimser veya kötümser kilitleme istediğinizi söylediğiniz sürece, onu yeterince iyi idare eder. Her neyse, bunun hiçbir şekilde kendinizi inşa etmeniz gereken bir şey olduğunu düşünmüyorum: onunla nasıl çalışacağınızı görmek için db motorunuzdaki seçenekleri kontrol edin.
jleach

Uygulamanızın bir masaüstü uygulaması ( yağ istemcisi ) olması çok fazla fark yaratmaz. Yüksek kullanılabilirliğe sahip, çok örnekli bir sunucu uygulamasıyla aynı şekilde tasarlanabilir.
Hosam Aly

Yanıtlar:


19

Burada size yardımcı olacak şeylerden biri terminolojidir. Burada tarif ettiğiniz şeye 'kötümser kilitleme' denir. Bu yaklaşımın ana alternatifi 'iyimser kilitleme'dır. Kötümser kilitlemede, her aktör güncellemeden önce kaydı kilitlemeli ve güncelleme tamamlandığında kilidi serbest bırakmalıdır. İyimser kilitlemede, başka hiç kimsenin kaydı güncellemediğini varsayarsınız. Kayıt başka bir aktör tarafından değiştirilirse güncelleme başarısız olur.

İki oyuncunun aynı şeyi aynı anda güncelleme şansı düşükse, iyimser kilitleme genellikle tercih edilir. Kötümser genellikle bu şans yüksek olduğunda veya güncellemenizin başlamadan önce başarılı olabileceğini bilmeniz gerektiğinde kullanılır. Deneyimlerime göre, iyimser kilitleme neredeyse her zaman tercih edilir çünkü kötümser kilitlemenin doğasında birçok sorun vardır. Sorunuzda en büyük sorunlardan biri ele alınmıştır. Kullanıcılar bir kaydı düzenlemek için kilitleyebilir ve ardından öğle yemeğine çıkabilirler. Azaltmanız bu konuda yardımcı olacaktır, ancak kullanıcı deneyimi iyimser yaklaşımdan daha iyi olmayacaktır ve muhtemelen çok daha kötü olacaktır. Örneğin, bir kullanıcı bir kayıt açar, güncellemeye başlar ve patronları masasında görünür. Başka bir kullanıcı kaydı düzenlemeye çalışır. Kilitli. İkinci kullanıcı denemeye devam eder ve 5 dakika sonra, kilidin süresi dolar ve ikinci kullanıcı kaydı günceller. İlk kullanıcı ekrana geri döner, kaydetmeye çalışır ve kilitlerini kaybettikleri söylenir. Şimdi aynı senaryoda iyimser kilitleme kullanmak dışında her şey aynı, ilk kullanıcının deneyimi hemen hemen aynı ama ikinci kullanıcı 5 dakika beklemiyor.

Düzenlediğiniz şema, kilit değeri için iyimser kilitleme uygulayarak büyük ölçüde geliştirilecektir, ancak önsezim iyimser kilitlemenin her şey için muhtemelen iyi olması ve is_locked alanından kurtulabilmenizdir.

Kullandığınız 'bulut DB'yi sağlamazsınız. Kendi çözümünüzü uygulamadan önce bunun için yerleşik özellikler olup olmadığını görmek için muhtemelen bunun özelliklerine bakmalısınız.

İşte temel tarif: is_locked alanı yerine sürüm numarası alanı var. Kaydı aldığınızda kaydın geçerli sürümünü alırsınız. Güncelleme yaptığınızda, güncellemeyi aldığınız ürünle eşleşecek şekilde sürüm alanına bağlı hale getirir ve başarıyı artırırsınız. Sürüm eşleşmezse, güncellemenin bir etkisi olmaz ve başarısızlık olarak rapor edersiniz.


Bu çok yardımcı bir cevap. Küçük bir "çarpışma" şansı olduğunda karamsar kilitlemenin neden caydırıldığını açıklayabilir misiniz? Sadece düzenlemeye başlamak için veritabanına gitmeyi gerektirdiği için mi yoksa ekstra karmaşıklık mı yoksa başka bir nedenden mi? Teşekkürler!
yitzih

3
@yitzih Önerilen bazı okumalar: Fowler ve arkadaşları, Kurumsal Uygulama Mimarisinin Kalıpları . Bu soruda, tüm seçenekleri ve bunları seçmenin nedenlerini iyi bir şekilde tartışan bir bölüm var.
Jules

2
@Jimmy - Cevabınız iyi. Bazı durumlarda, bir hata bildirimi yeterli değil. Bir kullanıcının kaydı güncellemek için birkaç dakika harcadığı bir durumu düşünün. Bu durumda, sadece başarısız olmak yeterince iyi olmayabilir, kullanıcıya uçuş içi değişikliklerini diğer kullanıcı tarafından yapılanlarla birleştirme fırsatı vermek isteyebilirsiniz. Ben iyimser kilitleme demeliydim olabilir gereksinimlerinize bağlı çatışma çözümlemesi gerektirir.
Jon Raynor

3
Kötümser kilitlemenin müşteriye açıklamanın çok daha kolay olduğunu belirtmek gerekir. İstemcinin o anda başka biri tarafından düzenlendiği için kayda erişemediğini bildiren bir ileti yazarsanız, istemci hem iyi anlar hem de genellikle kabul eder. Bunun yerine müşteriye kaydettikten sonra kaydetmenin mümkün olmadığını söylerseniz, başka bir kullanıcı, 7/10 tarafından zaten güncellendiğinden, istemci hayal kırıklığına uğrar ve / veya bu garip program davranışı için açıklama bekler.
Neil

2
@Neil Bu doğrudur ve bence iyimserlik daha uygun olduğunda kötümser kilitleme kullanılır. Genellikle iş akışı bir çarpışma olmasını pek mümkün kılmaz.
JimmyJames

0

Gönderen JimmyJames cevabı @ , biz soru hakkında gerçekten nasıl görebilirsiniz bir kullanıcı deneyimi .

Her şey bağlama bağlıdır. Bir kaydı güncellemek için ne kadar zaman ve çaba gerekir? Birden çok kullanıcı aynı belgeyi ne sıklıkla güncellemek ister?

Örneğin, kullanıcılarınız kaydı güncellemek için genellikle birkaç saniye ayırıyorsa ve çok az çekişme varsa, iyimser kilitleme muhtemelen yoludur. En kötüsü, bir kullanıcının bir belgeyi güncellemek için birkaç saniye, belki de bir dakika kadar zaman harcaması gerekir.

Belgeniz oldukça çekişmeli ancak iyi yapılandırılmışsa, kilitleri genişletmek için bir zamanlayıcı veya göze çarpmayan bir bildirim göstererek 30 saniyelik artışlarla tek tek alanları kilitlemelerine izin verebilirsiniz.

Ancak, kullanıcılarınız önemli miktarda zaman veya çaba harcarsa, diğer yaklaşımları da göz önünde bulundurmalısınız. Kaydınız iyi yapılandırılmış mı? Kullanıcılara sunucudaki sürüm ile kaydetmeye çalıştıkları sürüm arasında bir karşılaştırma (fark) gösterebilir misiniz? Farklılıkları vurgulayabilir misiniz? Değişiklikleri birleştirmelerine izin verebilir misiniz ? Kaynak kontrol araçlarınızla yaşamak istediğiniz deneyimi düşünün. Gerçekten tüm bu kodu tekrar yazmak zorunda kalmak istemiyorsunuz!

Ek ilham almak için Google Dokümanlar'a bakabilirsiniz. Belki de kullanıcılara yeni bir sürümün kaydedildiğine dair bir bildirim gösterebilirsiniz. Belki daha az tartışmalı bir zamanda geri dönmeyi seçebilmeleri için kaç kişinin rekor açık olduğunu gösterebilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.