فهم إدارة المعاملات المتكاملة مع الربيع والإسبات

قبل الحديث عن إدارة معاملات الربيع ، دعونا نفكر في كيفية إجراء عمليات البيانات في السبات عندما لا نستخدم الربيع. في السبات ، يجب علينا أولاً بدء المعاملة ، ثم إجراء عمليات البيانات ، ثم إرسال المعاملة ، وإغلاق المعاملة. السبب في أننا نفعل ذلك هو أن الالتزام التلقائي التلقائي لـ Hibernate هو خاطئ ، الأمر الذي يتطلب منا تقديم المعاملة يدويًا. إذا كنت لا ترغب في إرسال المعاملة يدويًا في كل مرة ، فيمكنك تعيينها لارتكاب المعاملة تلقائيًا في ملف hibernate.cfg.xml:

رمز XML

 <property name = "defaultaUtocommit"> <value> false </value> </surrent>

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

ينقسم تكوين المعاملة التصريحي بشكل أساسي إلى الخطوات التالية:

1. تكوين المعاملات التعريفية

(1) تكوين مدير المعاملات ؛

(2) خصائص انتشار المعاملة ؛

(3) تلك الفئات والأساليب تستخدم المعاملات.

 <!-قم بتكوين SessionFactory بأن مدير المعاملات يحدد وظيفته وتسليم المعاملة إلى الربيع للمعالجة-> <Bean id = "TransactionManager"> <property name = "sessionfactory"> <ref bean = "sessionfactory"/> </property> </bean> <! المعاملات-manager = "TransactionManager"> <tx: entributes> <tx: method name = "save*" spection = "required"/> <tx: method name = "delete*" spectation = "required"/> <tx: method name = "update =" upplication "/> <tx: method name = "*" read-only = "true"/> </tx: attributes> </tx: explive> <!-ما هي طرق تلك الفئات المشاركة في المعاملات-> <aop: config> <aop: pointcut id = "allservicemethod" expression = "execution (*com.coe.service.*.*.*. pointcut-ref = "allservicemethod" excloy-ref = "txAdvice"/> </aop: config>

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

2. كتابة أساليب منطق الأعمال

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

أخيرًا ، دعونا نلخص خصائص الانتشار العديدة للمعاملات:

1. spection_required: في حالة وجود معاملة ، يتم دعم المعاملة الحالية. إذا لم تكن هناك معاملة ، فسيتم تمكينها ؛

2. spection_supports: في حالة وجود معاملة ، يتم دعم المعاملة الحالية. إذا لم تكن هناك معاملة ، فإن تنفيذ غير المعاملات ؛

3. الانتشار _mandatory: في حالة وجود معاملة بالفعل ، يتم دعم المعاملة الحالية. إذا لم يكن هناك معاملة نشطة ، يتم إلقاء استثناء ؛

4. spection_requires_new: افتح دائمًا معاملة جديدة. في حالة وجود صفقة بالفعل ، يتم تعليق المعاملة الحالية ؛

5. spection_not_supported: قم دائمًا بتنفيذ غير متكافئ وعلقة أي معاملة موجودة ؛

6. الانتشار _never: دائمًا ما يتم تنفيذه غير محول ، في حالة وجود معاملة نشطة ، يتم طرح استثناء ؛

7. الانتشار_ إذا لم تكن هناك معاملة نشطة ، فقم بتنفيذها وفقًا لعلامة TransactionDefinition.propagation_required.

من خلال هذه المقالة ، آمل أن تساعدك على فهم إدارة المعاملات المتكاملة لـ Spring و Hibernate. شكرا لدعمكم لهذا الموقع!