تسليم رسالة JMS قبل الملء المعاملة

Question

لدي سيناريو بسيط للغاية ينطوي على قاعدة البيانات و jms. في خادم التطبيق (سمكة الزجاج). السيناريو ميت بسيط:

1. an EJB inserts a row in the database and sends a message.
2. when the message is delivered with an MDB, the row is read and updated. 

المشكلة هي أنه في بعض الأحيان يتم تسليم الرسالة قبل الالتزام بالإدراج في قاعدة البيانات. هذا أمر مفهوم في الواقع إذا اعتبرنا بروتوكول ارتكاب المرحلة 2:

1. prepare JMS
2. prepare database
3. commit JMS
4. ( tiny little gap where message can be delivered before insert has been committed)
5. commit database

لقد ناقشت هذه المشكلة مع الآخرين, ، ولكن الجواب كان دائما: "غريب، يجب أن تعمل خارج الصندوق".

أسئلتي هي بعد ذلك:

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

---

فيما يلي المزيد من التفاصيل حول فهمي للمشكلة:

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

لم أجد أي طريقة للتحكم في ترتيب المشاركين في المعاملات الموزعة في مواصفات JTA و JCA و JPA في وثائق Glassfish. يمكننا أن نفترض أنها سيتم تجنيدها في المعاملة الموزعة وفقا للترتيب عند استخدامها، ولكن مع orm مثل JPA، من الصعب معرفة متى يتم مسح البيانات وعندما يتم استخدام اتصال قاعدة البيانات حقا. اي فكرة؟

Answer 1

أنت تعاني من حالة سباق XA 2-PC الكلاسيكية. يحدث في بيئات الإنتاج.

هناك 3 أشياء تأتي إلى ذهني.

1. الأمثل الوكيل الأخير حيث JDBC هو مورد غير XA. (تفقد دلالات الاسترداد)
2. لديك JMS الوقت إلى التسليم. (تخسر عمدا في الوقت الحقيقي)
3. بناء إعادة المحاولة في رمز JDBC. (أقل تأثير على الوظائف)

يحتوي WeBlogic على تحسين هذه المشكلة هذه المشكلة ويمنحك جميع ضمانات XA.