البحث عن توصية بشأن قفل السجلات داخل نظام موزع

Question

نحن نحاول التوصل إلى نمط تصميم موصى به لفريقنا عندما يتعلق الأمر بقفل التسجيل.تسير المدرسة الفكرية النموذجية على النحو التالي:1.يختار المستخدم سجلًا من القائمة 2.قفل السجل مع معرف المستخدم 3.قم بتحميل سجل السجل المقفل (بدون قفل، ثم سبقك شخص ما إليه).

هل أفتقد شيئًا ما، أم يبدو أن هذه هي الطريقة الوحيدة للقيام بذلك؟((في حالتنا، قد يكون القفل المتفائل مرهقًا ومربكًا للمستخدمين النهائيين.غالبًا ما تكون التعديلات كبيرة جدًا.))

Answer 1

التفاصيل التي قد تجعل إدارة الحل الخاص بك مكثفة هي التخلص من الأقفال بعد الأعطال أو فشل الاتصال.هذا هو المكان الذي تكمن فيه المفاضلة بين القفل المتفائل والمتشائم.يعد دمج التعديلات يدويًا أو إعادة إجرائها عند فشل القفل المتفائل أمرًا مؤلمًا، ولكن التطهير بعد الأعطال في نماذج القفل المتشائمة والمستمرة يخلق مشكلة خاصة به (كما سيخبرك أي شخص دعم مستخدمي أنظمة المحاسبة المدعومة من Pervasive في التسعينيات بإسهاب نظرًا الفرصه)

إحدى الإجابات هي استخدام آليات RDBMS لإدارة المعاملات والتزامن:احصل على السجل باستخدام SELECT FOR UPDATE أو أي صيغة تناسب بيئتك ومستوى عزلتك.إذا تعطل أحد عملائك أو تم قطع اتصاله، فسيتم التراجع عن المعاملة وتحرير القفل.

في بيئة غير متصلة مثل الويب أو بيئة يتم فيها فقدان الاتصالات واستعادتها بشكل متكرر، يمكن أيضًا أن يعمل النموذج المستند إلى الجلسة مع انتهاء مهلة الجلسة:

• حاول مسح التأمين الموجود في السجل إذا كان لجلسة منتهية الصلاحية
• محاولة قفل السجل بمعرف الجلسة (تفشل إذا فشلت الخطوة السابقة)
• حدد السجل المقفل (لم يتم إرجاع أي سجل إذا فشلت الخطوة السابقة)

لذلك يتم تحرير القفل عند انتهاء الجلسة.لا حاجة إلى إزالة الأقفال يدويًا بعد الأعطال وبعض التسامح مع مشكلات العميل/الاتصال.يستغرق الأمر المزيد من العمل للبرمجة بالرغم من ذلك.