في طابور تجهيز تقارير افتراضي، يختار عاملان أول مهمة جاهزة في اللحظة نفسها. إذا قرأ كل منهما الصف ثم بدأ التنفيذ خارج معاملة الحجز، فقد ينتج تقريران للمهمة نفسها. المطلوب اختبار انتقال الحالة تحت التزامن، وليس فقط التأكد أن الاستعلام يرجع صفوفًا.
ماذا يتجاوز الاستعلام؟
مع FOR UPDATE SKIP LOCKED يتجاوز PostgreSQL الصفوف التي لا يمكن قفلها فورًا. يصلح هذا لنمط طابور بعمال متعددين، لكنه يعطي رؤية غير كاملة للصفوف الجاهزة في تلك اللحظة. لا تستخدم النتيجة لحساب عدد الطلبات المعلقة، ولا تفترض أن العبارة تتجاوز كل أقفال الجداول.
المرجع: PostgreSQL SELECT locking clause.
نفّذ تجربة بجلستين
جهز ثلاثة سجلات تجريبية بحالة جاهز. في الجلسة الأولى، افتح معاملة واحجز أول سجل بترتيب ثابت يستخدم أولوية ومعرّفًا فريدًا. اترك المعاملة مفتوحة. في الجلسة الثانية، نفذ الاستعلام نفسه مع التجاوز؛ راقب أن الحجز ينتقل لسجل مختلف. أعد الاختبار بعد التراجع في الجلسة الأولى وتأكد أن المهمة الأصلية تصبح مرئية من جديد.
اجعل الحجز وتسجيل الملكية خطوة واحدة
قبل إغلاق معاملة الحجز، حدّث حالة السجل وسجل معرف العامل ووقت الحجز. اترك إنشاء التقرير خارج المعاملة حتى لا تمسك الأقفال أثناء عمل طويل. افحص حالة عامل توقف بعد الحجز؛ يحتاج الطابور سياسة استرداد للحجوزات القديمة. وإن أصبح للمهمة أثر خارجي، استخدم مفتاح عملية يحمي من تنفيذ الأثر مرتين.
قبول التزامن بالنتائج
تحقق من عدم اشتراك العاملين في معرف المهمة المحجوزة، ومن إمكانية التقاط مهمة تُركت بعد تعطل عامل. اختبر أيضًا نتيجة فارغة بينما كل المهام مقفولة؛ هذه الحالة تعني عدم وجود صف متاح للحجز حاليًا، ولا تثبت فراغ الطابور. احتفظ بسجل معرفات المعاملات ونتائجها من بيانات اختبار فقط.
لربط الاختبار بتنفيذ مشروعك، راجع تطوير أنظمة الشركات وأنظمة ERP.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
