تعلم معاملات الربيع وقوائم الرسائل

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

1. المشكلة الناشئة:

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

شفرة:

 service (orderapi) الطبقة العامة orderapiimpl تنفذ orderapi {resource mqservice mqservice ؛ @orderdao orderdao ؛ Public Void Push (String orderid) {// تحديث حالة الطلب ، كانت الحالة السابقة 1 updatestatus (orderid ، 3) ؛ // إنشاء رسالة mqservice.produce (orderid) ؛ } public viod updatestatus (String orderid ، integer status) {orderdao.updatestatus (orderid ، status) ؛ }}

سبب المشكلة: جميع الطرق في OrderAPI لديها معاملات ، و serpation_required نوع المعاملة ، وبالتالي سيتم تقديم تشغيل طريقة الدفع على البيانات بعد تنفيذ كل رمز الدفع. قبل إرسال المعاملة ، قد يتم إنشاء رسالة قائمة انتظار الرسائل ، وبالتالي فإن حالة الطلب المستهلكة في استعلام قائمة انتظار الرسائل من قاعدة البيانات قد تكون 1. من أجل جعل الأخطاء أكثر وضوحًا ، يمكنك إضافته في نهاية طريقة الدفع:

 جرب {thread.sleep (10000) ؛} catch (interruptedException e) {// todo catch catch e.printstacktrace () ؛}

وبهذه الطريقة ، ستجد أنه يجب عدم تعديل حالة الطلب عند استهلاك رسالة الاستهلاك.

2. حل المشكلة:

الحل: عند تحديث البيانات ، قم بإنشاء شيء جديد للتأكد من أنه بعد تنفيذ رمز التحديث ، تم ارتكاب المعاملة التي تقوم بتحديث قاعدة البيانات. (تأكد من تقديم عملية قاعدة البيانات قبل إنشاء الرسالة)

وفقًا للمخطط أعلاه ، فإن أول شيء أفكر فيه هو تعديل نوع المعاملة مباشرة لطريقة updatestatus ؛ لقد قمت بتغيير نوع المعاملة لهذه الطريقة إلى servation_requires_new (إنشاء معاملة جديدة ، إذا كانت المعاملة موجودة حاليًا ، قم بتعليق المعاملة الحالية).

ولكن هناك شيئان غير مناسبان:

1. قد يؤثر التعديل القسري لنوع معاملة updatestaus على العمليات الأخرى.

2. لا تعمل ، لم يتم إنشاء معاملة جديدة في طريقة updatestaus.

شرح حول النقطة الثانية: يضيف Spring المعاملات من خلال BeannameautoproxyCreator ، والذي يضيف فقط المعاملات إلى كائنات الفاصوليا. الآن لن يؤدي الاتصال إلى الأساليب داخل الفصل إلى إنشاء أشياء جديدة.

لذلك بعد تجربة ما سبق ، قمت بإنشاء فصل جديد:

 service ("orderextapi") الطبقة العامة orderextapiimpl {resource orderapi orderapi ؛ public void updateStatusNewPropagation (String orderid) {orderapi.updatestatus (orderid) ؛ }}

وأضف المعاملة الانتشار_

هذه الفئة هي فقط لإنشاء معاملة جديدة لطريقة updatestaus في Orderapi.

حسنًا ، تم حل الخلل حتى الآن.

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

الرمز في Orderapi النهائي هو كما يلي:

 service (orderapi) الطبقة العامة orderapiimpl تنفذ orderapi {resource mqservice mqservice ؛ Resource orderdao orderdao ؛ Resource orderextapiimpl orderextapi ؛ Public Void Push (String orderid) {// تحديث حالة الطلب ، كانت الحالة السابقة 1 OrderExtapi.updatestatusNewPropagation (orderid ، 3) ؛ // إنشاء رسالة -سوف يكتشف الإنتاج ما إذا كان هناك استثناء. عندما يتم إرجاع 1 ، فهذا يعني أن رسالة الإنتاج ناجحة. استجابة الاستجابة = mqservice.produce (orderid) ؛ if (response.getCode ()! = 1) {log.info ("رسالة إنتاج قائمة انتظار الرسائل استثناء:" + response.geterrormsg ()) // استثناء رسالة الإنتاج ، إعادة تعيين الحالة وانتظر إعادة التنفيذ التالي orderextapi.updatestatnewpropagation (orderid ، 1) ؛ }} public viod updatestatus (String orderid ، integer status) {orderdao.updatestatus (orderid ، status) ؛ }}

ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.