الخلاصة

  • أوصى RFC 2372 بإنشاء prepared-recovery record قبل PREPARED وcommit-recovery record قبل COMMIT في حالة Prepared، والاحتفاظ بكل سجل حتى وصول دليل الحل المحدد له.
  • حدّد هذا الترتيب عهدة محلية دائمة، لكنه لم يثبت وصول البايتات إلى وسيط ثابت، ولا نجاتها من العطل، ولا استعادة هوية المعاملة الصحيحة، ولا معرفة التطبيق بالنتيجة.

تبدو كلمة PREPARED مؤقتة، لكنها اللحظة التي يفقد فيها المشارك حرية التراجع منفرداً بعد العطل. قد يكون الطرف الأعلى قد جمع الأصوات واختار الالتزام. عندما يقول الطرف التابع PREPARED فهو يعد بأن يتذكر المعاملة حتى لو اختفى المقبس أو العملية أو الجهاز الذي حمل المحادثة.

صدر RFC 2372 في يوليو 1998 بوصفه RFC معلوماتياً، لا معياراً من معايير الإنترنت. شرح سيناريوهات TIP ومتطلباته وملاحظات تنفيذه، ووصف العلاقة بين أوامر البروتوكول والسجل بأنها إرشادية وليست نهائية. لم يعرض منتجاً أو نشرًا أو محرك تخزين أو اختبار انقطاع. لقد حدّد واجباً بقي على البرمجية الفعلية أن تثبت أداءه.

كان على الطرف التابع إنشاء سجل prepared قبل إرسال PREPARED، والاحتفاظ به حتى ABORT أو COMMIT أو QUERIEDNOTFOUND. وما دام السجل موجوداً فلا يرسل COMMITTED أو NOTRECONNECTED. أما الطرف الأعلى فبعد تلقي PREPARED وقبل إرسال COMMIT من حالة Prepared ينشئ سجل commit، ويبقيه حتى COMMITTED أو NOTRECONNECTED.

لم تكن القاعدة مجرد نصيحة بتسجيل الأحداث المهمة. حوّلت PREPARED حرية محلية إلى واجب تجاه المنسق، وحوّل COMMIT القرار إلى شيء قد يلزم تكراره بعد الفشل. حذف السجل كان ادعاءً بأن دليلاً مسمّى قد أنهى الواجب، لا مجرد تنظيف مساحة.

قد يكون الرد السلبي دليلاً إيجابياً

بعد فقد الاتصال يستطيع الطرف الأعلى إرسال RECONNECT بهوية معاملة الطرف التابع، مستعيداً إياها من السجل عند الحاجة. إذا بقي التابع في Prepared يجيب RECONNECTED. وإذا كان قد تلقى COMMIT وأرسل COMMITTED ثم نسي الحالة المكتملة، يجيب NOTRECONNECTED. ضمن التاريخ الصحيح لم يكن «لا» فشلاً بالضرورة، بل ربما أثبت أن التنفيذ انتهى.

ويستطيع الطرف التابع إرسال QUERY. تعني QUERIEDEXISTS أن الطرف الأعلى ما زال يعرف المعاملة وسيعيد الاتصال لاحقاً. وتسمح QUERIEDNOTFOUND بالإلغاء، لأن الطرف الأعلى ربما أرسل ABORT ولم يتلق ABORTED ثم نسي معاملة presumed-abort. لا معنى للغياب من دون الدور والحالة والهوية وتسلسل الرسائل.

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

اختلفت إيصالات الحذف باختلاف الدور. انتظر التابع قراراً أو نتيجة استعلام تحرره من Prepared؛ وانتظر الأعلى تأكيد المشارك أو الحالة المحددة التي يكون فيها المشارك قد أكمل ونسي. لم يكن انتهاء المهلة أو إعادة التشغيل أو ضيق القرص أو ثقة المشغّل بديلاً عن تلك الإشارات.

تستطيع المهلات المحلية الحد من احتجاز الموارد وحل الجمود، لكن مرور الوقت لا يثبت النتيجة. تحرير المورد، وحل حالة البروتوكول، ومعرفة ما حدث بعد ذلك حقائق منفصلة.

بين «الإنشاء» و«الدوام» مسار تخزين كامل

ماذا يعني إنشاء السجل: الكتابة في ذاكرة العملية، أم مخبأ النواة، أم دفتر التخزين، أم الوسيط المادي، أم نسخة في نطاق فشل آخر؟ ماذا يضمن إقرار التخزين؟ هل تتمزق الكتابة؟ هل يمكن العثور على الهوية بعد ضياع الفهرس المتطاير؟ هل يسبق مرسل غير متزامن اكتمال الكتابة ويرسل PREPARED مبكراً؟

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

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

التفويض نقل الحراسة ولم يلغها

أمكن لعميل خفيف تفويض التنسيق إلى خادم كامل والاستغناء عن سجل معاملة محلي. لم تختف مسؤولية الاستعادة؛ انتقلت إلى الخادم. على التدقيق أن يتبعها: أي سجل حُفظ، وبأي هوية، وقبل أي تصريح، وبعد أي إيصال حُذف؟

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

وهذا يميز المقال عن المادة المنشورة حول RFC 2371. تناولت تلك المادة فصل القناتين وأن COMMIT ليس إيصال عمل تجارياً. أما هنا فالموضوع هو سلسلة الدليل المحلية: سجل prepared، وسجل commit، والهوية المستعادة، والإشارة البعيدة الدقيقة التي تسمح بحذف كل واحد.

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

أمن القناة لم يثبت حالة السجل

بقيت مصادقة التطبيق وتفويضه خارج TIP. أمكن لـ TLS مصادقة الطرفين وتشفير الأوامر عند التفاوض عليه. حمى ذلك من أوامر غير مصرح بها أو انتحال مدير موثوق، لكنه لم يثبت دوام السجل أو تفويض العمل أو تغير المورد أو اعتراف نظام آخر بالنتيجة.

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

تمنع عدسة طبقات الواقع لدى Heng Lu ضغط طلب التطبيق والفعل المحلي وحالة TIP والسجل وإقرار التخزين والرسالة والهوية المستعادة ورد النظير ونتيجة المورد ومعرفة العميل في كلمة واحدة. قد تكون طبقة مؤكدة وتظل التالية مجهولة.

مواصفة أولية دنيا وتركت عبء الإثبات محلياً

لم يفرض RFC صيغة سجل أو محركاً أو API أو لوحة تشغيل موحدة. احتاج التشغيل البيني إلى أوامر وأدوار وهويات ومعنى مشترك للاستعادة، لا إلى قاعدة بيانات واحدة. ووفق فكرة Heng Lu عن المواصفة الأولية الدنيا، بقي القرار التقني اللاحق محلياً.

جاءت الحرية مع عبء إثبات: أن السجل سبق الرسالة، ونجا من فقد الطاقة، وظهر من دون فهرس متطاير، وارتبط بالمورد الصحيح، ولم يختف إلا بعد الإيصال المسموح. الإشارة إلى RFC تخبرنا ما الواجب، لا هل تحقق.

ما زالت الأنظمة الموزعة تقول «مقبول» و«منسوخ» و«جاهز» و«مصرح» قبل الفشل. كل كلمة تنشئ توقعاً عما سيبقى بعده. درس RFC 2372 ليس أن وجود سجل يجعل القول صحيحاً، بل أن كل قول له أثر بعد العطل يحتاج إلى دليل دائم قابل للفحص يسبقه.

المصادر