التعامل مع استعلامات قاعدة البيانات التي تفشل بسبب فشل الخادم

Question

في بيئة مع مجموعة تجاوز فشل SQL Server أو مرآة، كيف تفضل التعامل مع الأخطاء؟ يبدو أن هناك خياران:

1. فشل طلب العميل الحالي بأكمله، والسماح للمستخدم المحاولة
2. قبض على الخطأ في دال الخاص بك، وإعادة المحاولة هناك

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

أي حجج بطريقة أو بأخرى ستكون موضع تقدير. إذا كنت تستخدم النهج الثاني، فهل لديك غلاف قياسي يساعد على تبسيط التنفيذ؟ وفي كلتا الحالتين، كيف تقوم بنية التعليمات البرمجية الخاصة بك لتجنب قضايا مثل تلك المتعلقة بعدم وجود Idempotency في الأمر الذي فشل؟

Answer 1

رقم 2 يمكن أن يكون حلقة لانهائية. ماذا لو كانت الشبكة ذات الصلة، أو يحتاج الكمبيوتر المحلي إلى إعادة تشغيله، أو أيا كان؟

رقم 1 مزعج للمستخدمين، بالطبع.

إذا سمحت بالوصول فقط عبر موقع ويب، فلن ترى الخطأ أبدا على أي حال ما لم يحدث الفشل في منتصف المكالمة. بالنسبة لنا، هذا غير مرجح وقد فشلنا دون إدراك المستخدمين النهائيين.

في الحياة الحقيقية، قد لا يكون لديك DAL نظيفة لطيفة على خادم ويب. قد يكون لديك ورقة Excel التي تربط (معظم البيانات المالية) أو Winforms حيث يتم فتح الاتصال، لذلك لديك خيار واحد فقط.

فشل قد يستغرق الأمر سوى بضع ثوان على أي حال. إذا كان استعادة DB يستغرق أكثر من ذلك، فسيكون لديك مشكلات أكبر على أي حال. وإذا حدث ذلك في كثير من الأحيان ما يكفي للتفكير في التعامل معها، حسنا ...

باختصار، سيحدث ذلك، لكنك نادرا ما تريد أن تعرف ورقم 1 سيكون أفضل. IMHO.