الخلاصة

  • في Argus يجمع الـguardian العمليات والكائنات ومسؤولية الاستعادة، وتجعل الـatomic action تغييرات الكائنات القابلة للاستعادة المشاركة قابلة للتسلسل ونافذة كلها أو ملغاة كلها.
  • لا يثبت الـcommit اكتمال جهاز خارجي أو إجراء بشري أو إدخال وإخراج غير مُدار، ولا يثبت هوية الشخص أو غرض العمل الكامن وراء الاستدعاء.

نجح الـcommit، لكن الآلة لم تتحرك

لنتخيل handler يحدّث كائن تحكم دائم، ثم يطلب من جهاز خارج عالم Argus تنفيذ حركة. يصل الـtopaction إلى قرار واضح. توافق كل الـguardians المشاركة. تُكتب النسخ الجديدة من الكائنات المستقرة. ويتلقى المستدعي نتيجة نجاح.

ومع ذلك تبقى الآلة ساكنة.

لا يوجد تناقض. يقدم Argus ضماناً قوياً للكائنات القابلة للاستعادة التي دخلت في الـaction، ولا يقدم ضماناً لجهاز لم يشارك. توحي كلمة commit بنهاية شاملة، لكنها في عمل Barbara Liskov وفريق Argus كانت خاصية دقيقة النطاق للغة وبيئة التشغيل.

جمع بحث عام 1983 Guardians and Actions، من تأليف Liskov وRobert Scheifler، بين تجريدين. يضم الـguardian موارد البرنامج الموزع وكائناته وعملياته في عقدة ويتحمل مسؤولية استعادتها. وتضم الـaction العمليات التي ينبغي أن تبدو متسلسلة، فإما أن تُنتج معاً الحالة الجديدة وإما أن تعيد الحالة السابقة القابلة للاستعادة. انتقلت معالجة الفشل بذلك من اتفاقات مرتجلة في كل تطبيق إلى آلية يمكن الاستدلال عليها.

ورسم هذا التقدم حدّاً للدليل أيضاً: للـcommit سلطة داخل مجموعة المشاركين، أما خارجها فتبدأ الحاجة إلى إيصال آخر.

نطاق للاستعادة، لا حارس لكل العالم

يشبه الـguardian وحدة برمجية تعيش أطول من عملية واحدة. يحتفظ بكائنات، ويشغّل عمليات، ويعرض handlers على guardians أخرى. وبعد فشل العقدة يمكن إعادة بناء حالته القابلة للاستعادة، بينما تُهيأ الحالة volatile من جديد. وهكذا تصبح مسؤولية الاستعادة محددة.

قد يوحي الاسم بمراقب أمني شامل، لكن هذا أوسع من المقصود. يجمع الـguardian موارد البرنامج ومسؤولية الاستعادة، لا كل ملف أو جهاز أو شخص أو خدمة تتعامل معها المؤسسة.

يظهر الحد في نموذج التخزين. كانت المتغيرات stable جذوراً تصل إلى resilient objects. وقبل commit للـtopaction كان يجب كتابة الحالة الجديدة للكائنات المستقرة المعدّلة في stable storage. أما المتغيرات volatile فتُهيأ من جديد عند الاستعادة. والإشارة من متغير stable إلى كائن غير resilient لا تمنحه تلقائياً دواماً معاملاتياً؛ يظل نوع الكائن وتنفيذ الاستعادة حاسمين.

لذلك فقول إن Argus «جعل البرامج الموزعة موثوقة» وصف فضفاض. الأدق أنه جعل فئة محددة من الحالة قابلة للاستعادة وفق افتراضات فشل محددة. التعريف هو الذي صنع الضمان.

استدعاء الـhandler يبني شجرة actions

لم يكن العمل البعيد انحرافاً خفياً خارج المعاملة. ينشئ استدعاء handler لدى guardian آخر call action عند المستدعي وactivation action عند الهدف. تعبر الوسائط والنتائج بالنسخ القيمي، ويشارك مسار العودة في تحديد نهاية الـsubactions.

عادةً ما يؤدي return أو signal عادي إلى commit للـactivation. أما abort return وabort signal فيؤديان إلى abort. لذلك لا يساوي الاستثناء تلقائياً فشل المعاملة. فإذا كان استثناء ما يجب أن يمنع commit للعمل المحيط، فعلى البرنامج التقاطه عند حد الـaction المناسب.

يمكن لـsubaction أن تفشل من دون أن تُسقط الأب بالضرورة. وعندما تنجح تنتقل الأقفال والنسخ المؤقتة إلى الأب، وتبقى النتيجة مشروطة بنجاحه ثم بنجاح الـtopaction. عبارة «نجح commit للـsubaction» لا تعني أنها أصبحت دائمة بصورة مستقلة عن المستدعي.

الـtopaction هو جذر الشجرة. عند الـcommit ينسق النظام بين الـguardians ويستخدم two-phase commit عندما يتطلب القرار الموزع ذلك، ثم يسجل النسخ الجديدة من الكائنات المستقرة التي عدلتها الـaction وفروعها الناجحة. وعند الـabort تعود الحالة المُدارة معاملاتياً إلى نسختها السابقة.

تمنع هذه الطبقات ثلاث مبالغات: نجاح activation ليس بعدُ commit للـtopaction؛ ونجاح subaction ليس استقلالاً؛ وcommit للـtopaction لا يثبت شيئاً عن غير المشاركين.

كشف الـorphan غموض الشبكة

قد يفشل الاستدعاء الموزع بصورة ملتبسة. تختفي عقدة بينما يستمر العمل في مكان آخر، أو يفقد المستدعي مسار العودة من دون أن يعرف إن كانت الـactivation البعيدة قد توقفت. سمّى Argus الـaction التي مات سلفها أو تعذر وصول نتيجتها إلى سلالتها orphan.

لم تكن آلية الـorphan مجرد مهلة زمنية. هدفت إلى إنهاء الـorphans بالـabort، والأهم إلى منعها من رؤية atomic data غير متسقة بعد فقدان السلف الشرعي. ويسجل الدليل حقيقة تشغيلية مزعجة: قد يحصل المستدعي على unavailable بينما يستمر نشاط بعيد في العمل بصفة orphan.

ومن ثم فاستنتاجان غير آمنين. غياب النتيجة لا يثبت أن شيئاً لم يُنفذ. وإجبار الـabort داخل نظام الـactions لا يثبت تراجع أثر خارجي غير مُدار. يعتمد الضمان على تواصل الـactions عبر بيانات ذرية. نبضة محرك أو صفحة مطبوعة أو رسالة سُلّمت لخادم خارجي أو تعليمات أُعطيت لإنسان لا تعود إلى الوراء لمجرد اختفاء سلف Argus.

حل Argus مشكلة صعبة بتحديد الحالة التي يستطيع التحكم فيها، لا بادعاء أن العالم كله معاملة واحدة.

كان open nesting استثناءً مقصوداً

تظل الـsubactions العادية مشروطة بالأب. وقدم Argus أيضاً nested topaction يمكنه commit بصورة مستقلة والبقاء حتى إذا حدث abort للـaction الخارجية لاحقاً. هذا هو open nesting.

يناسب ذلك الآثار التي ينبغي أن تبقى، مثل سجل تنسيق مقصود الدوام، لكنه يغير معنى الدليل. يجب على المبرمج التأكد من أن الأثر المستقل آمن بعد فشل الأب ويلتزم بقيود التسلسل. بقاؤه ليس تسرباً غامضاً من الذرية، بل استثناء مصرحاً به من نطاق الـrollback.

تعيد أنماط outbox وخطوات saga وكتابات التدقيق المستقلة اكتشاف البنية نفسها اليوم. الاسم أقل أهمية من الانضباط: يجب تسمية الأثر ذي الـcommit المستقل، لا إخفاؤه داخل تقرير يزعم أن العملية الأم تراجعت بلا بقايا.

يحسم الـcommit الحالة، لا الهوية أو النية

تربط هوية الـaction العمل لأغراض التزامن والاستعادة، لكنها لا تصادق على إنسان. قد يعرف الـhandler الوسائط والنتائج وسلسلة الـaction، من دون أن يعرف أي موظف أو مسؤول منح التفويض التجاري.

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

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

للفضل العلمي حدوده أيضاً

Liskov هي المدخل الطبيعي لأنها قادت البرنامج وكتبت العرض الناضج عام 1988. لكن Argus عمل جماعي. كتب Guardians and Actions كل من Barbara Liskov وRobert Scheifler، وشكر البحث مجموعة التصميم، وخصوصاً Maurice Herlihy وPaul Johnson وWilliam Weihl. ويسمي دليل 1987 Liskov وMark Day وHerlihy وJohnson وGary Leavens وScheifler وWeihl. أما بحث التنفيذ فكتبه Liskov وDorothy Curtis وJohnson وScheifler.

حفظ هذه الأسماء ليس مجاملة. فالحد بين فكرة اللغة وبروتوكول الاستعادة والدليل والتنفيذ العامل جزء من التاريخ التقني. لا ينبغي لاسم مشهور أن يمتص عمل النظام كله، كما لا ينبغي لـcommit واحد أن يمتص نتائج العالم كله.

المصادر