تفسير استخدام الربيع @ترانساكاكال

ملخص

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

يوفر Spring Framework تجريدًا ثابتًا لإدارة المعاملات ، مع خصائصه على النحو التالي:

توفير نماذج برمجة متسقة لواجهة برمجة تطبيقات المعاملات المختلفة ، مثل JTA (JAVA Transaction API) و JDBC و Hibernate و JPA (API Java Persistence و JDO (كائنات بيانات Java)

يدعم إدارة المعاملات التصريبية ، وخاصة إدارة المعاملات التعريفية على أساس التعليقات التوضيحية ، وهو أمر بسيط وسهل الاستخدام

يوفر واجهة برمجة تطبيقات برمجة أبسط من برمجة برمجة أخرى من واجهات برمجة تطبيقات المعاملات مثل JTA

تكامل مثالي مع تجريد الوصول إلى بيانات الربيع

طريقة إدارة المعاملات

يدعم Spring طريقتين: إدارة المعاملات البرمجية وإدارة المعاملات التعريفية.

تستخدم إدارة المعاملات البرنامجية TransactionTemplate أو تستخدم مباشرة منصة stransactionmanager الأساسية. لإدارة المعاملات البرنامجية ، يوصي Spring باستخدام TransactionTemplate.

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

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

هناك أيضًا طريقتان شائعتين لإدارة المعاملات التعريفية. أحدهما هو ملف تكوين XML استنادًا إلى مساحات أسماء TX و AOP ، والآخر يعتمد على التعليق التوضيحي transactional. من الواضح أن الطريقة القائمة على التعليقات التوضيحية هي أبسط وأسهل في الاستخدام وأكثر انتعاشًا.

الالتزام التلقائي (AutoCommit) وما إذا كان سيتم الإرسال تلقائيًا عند إغلاق الاتصال

التقديم التلقائي

بشكل افتراضي ، تكون قاعدة البيانات في وضع التقديم التلقائي. كل بيان في معاملة منفصلة. عند اكتمال تنفيذ هذا البيان ، إذا نجح التنفيذ ، يتم تقديم المعاملة ضمنيًا.

إذا فشل التنفيذ ، يتم تراجع المعاملة ضمنيًا.

بالنسبة لإدارة المعاملات العادية ، توجد مجموعة من العمليات ذات الصلة في معاملة ، لذلك يجب إيقاف تشغيل وضع الالتزام التلقائي لقاعدة البيانات. ومع ذلك ، لا داعي للقلق بشأن هذا ، سيقوم Spring بتعيين ميزة الالتزام التلقائي للاتصال الأساسي بـ False.

org/springframework/jdbc/datasource/datasourcetransactionmanager.java

 // التبديل إلى الالتزام اليدوي إذا لزم الأمر. هذا مكلف للغاية في بعض برامج تشغيل JDBC ، // لذلك لا نريد القيام بذلك دون داع (على سبيل المثال إذا قمنا بتكوين مجموعة الاتصال بشكل صريح // لضبطه بالفعل) .IF (con.getautocommit ()) {txobject.setMustrestoreAutocommit (true) ؛ if (logger.isdebugenabled ()) {logger.debug ("تبديل اتصال JDBC [" + con + "] إلى الالتزام اليدوي") ؛ } consetautocommit (false) ؛}

توفر بعض تجمعات اتصال البيانات إعدادات لإيقاف التزامات المعاملة التلقائية ، والتي من الأفضل إيقاف تشغيلها عند إعداد تجمع الاتصال. ومع ذلك ، لا يوفر C3P0 هذه الميزة ولا يمكن أن يعتمد إلا في فصل الربيع لتعيينها.

نظرًا لأن مواصفات JDBC تنص على أنه عند إنشاء كائن الاتصال ، يجب أن يكون في وضع الالتزام التلقائي ، وهو القيمة الافتراضية عبر DBMS ، ويجب إيقاف الالتزام التلقائي بشكل صريح إذا لزم الأمر. يلتزم C3P0 بهذه المواصفات ويسمح لرمز العميل بتعيين وضع التقديم المطلوب صراحة.

ما إذا كان يجب الإرسال تلقائيًا عند إغلاق الاتصال

عند إغلاق الاتصال ، ما الذي يجب معالجته إذا كانت هناك معاملة غير ملتزم بها؟ لا تذكر مواصفات JDBC أن السياسة الافتراضية لـ C3P0 هي تراجع أي معاملات غير ملتزم بها. هذه هي الاستراتيجية الصحيحة ، ولكن لا يوجد اتفاق بين مقدمي سائقي JDBC حول هذه المسألة.

إن خاصية CommomitonClose لـ C3P0 خاطئة بشكل افتراضي ، لذلك ليست هناك حاجة لعدم تحريكها. أو يمكنك تعيين هذه الخاصية بشكل صريح على FALSE ، والتي ستكون أكثر وضوحًا.

تكوين إدارة المعاملات التعريفي المستند إلى التعليقات التوضيحية

الربيع servlet.xml

 <!-دعم المعاملات-> <!-platformTransActionMnager-> <bean id = "txmanager"> <property name = "dataSource" ref = "datasource" /> </bean> <!-تمكين دعم التعليقات التوضيحية للمعاملات-> <tx: التعليقات التوضيحية-manager = "txmanager" />

أضف أيضًا مساحة اسم TX في servlet.xml

 ... xmlns: tx = "http://www.springframework.org/schema/tx" http://www.springframework.org/schema/tx/spring-tx.xsd ...

يشارك MyBatis تلقائيًا في إدارة معاملات الربيع دون تكوين إضافي. طالما أن مصدر البيانات المشار إليه من قبل org.mybatis.spring.sqlsessionfactorybean يتوافق مع مصدر البيانات المشار إليه بواسطة DatasourCetransActionManager ، وإلا فلن تعمل إدارة المعاملات.

بالإضافة إلى ذلك ، تحتاج إلى تنزيل حزمة التبعية aopalliance.jar ووضعها في دليل الويب/lib. خلاف ذلك ، سيتم الإبلاغ عن استثناء عند تهيئة الربيع

java.lang.noclassdeffounderror: org/aopalliance/intercept/methodInterceptor

ميزات المعاملات الربيع

جميع فئات سياسة إدارة المعاملات في فصل الربيع ورثت من org.springframework.transaction.platformTransactionManager واجهة

 الواجهة العامة platformTransActionManager {TransactionStatus getTransaction (تعريف المعاملات) يلقي TransactionException ؛ الالتزام void (حالة المعاملات) يلقي المعاملة. تراجع باطل (حالة المعاملات) يلقي المعاملة ؛}

تحدد واجهة TransactionDefinition الخصائص التالية:

مستوى عزل المعاملة

يشير مستوى العزلة إلى درجة العزلة بين العديد من المعاملات المتزامنة. يتم تعريف خمس ثوابت تمثل مستويات العزلة في واجهة المعاملة:

TransactionDefinition.isolation_default: هذه هي القيمة الافتراضية ، مما يشير إلى مستوى العزل الافتراضي المستخدم في قاعدة البيانات الأساسية. بالنسبة لمعظم قواعد البيانات ، عادة ما تكون هذه القيمة معاملة definition.isolation_read_committed.

TransactionDefinition.isolation_read_uncommitt: يشير مستوى العزلة هذا إلى أن معاملة واحدة يمكنها قراءة البيانات المعدلة بواسطة معاملة أخرى ولكن لم يتم ارتكابها بعد. هذا المستوى لا يمنع القراءة القذرة والقراءة المتكررة والقراءة الوهمية ، لذلك نادراً ما يتم استخدام مستوى العزلة. على سبيل المثال ، ليس لدى PostgreSQL هذا المستوى بالفعل.

TransactionDefinition.isolation_read_committ: يعني مستوى العزلة أن معاملة واحدة يمكنها فقط قراءة البيانات التي ارتكبتها معاملة أخرى. يمنع هذا المستوى القراءة القذرة ، والتي هي أيضًا القيمة الموصى بها في معظم الحالات.

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

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

سلوك اتصال المعاملات

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

TransactionDefinition.propagation_required: إذا كانت المعاملة موجودة حاليًا ، انضم إلى المعاملة ؛ إذا لم تكن هناك معاملة حاليًا ، فقم بإنشاء معاملة جديدة. هذه هي القيمة الافتراضية.

TransactionDefinition.propagation_requires_new: إنشاء معاملة جديدة ، وإذا كانت المعاملة موجودة حاليًا ، فسيتم تعليق المعاملة الحالية.

TransactionDefinition.propagation_supports: انضم إلى المعاملة إذا كانت هناك معاملة حاليًا ؛ إذا لم تكن هناك معاملة في الوقت الحالي ، فستستمر في العمل بطريقة غير محطمة.

TransactionDefinition.propagation_not_supported: تشغيل بطريقة غير محطمة ، وإذا كانت المعاملة موجودة حاليًا ، فسيتم تعليق المعاملة الحالية.

TransactionDefinition.propagation_never: تشغيل بطريقة غير نار ، يلقي استثناء في حالة وجود معاملة حاليًا.

TransactionDefinition.propagation_mandatory: انضم إلى المعاملة إذا كانت هناك معاملة حاليًا ؛ إذا لم يكن هناك معاملة حاليًا ، يتم طرح استثناء.

TransactionDefinition.propagation_nested: إذا كانت المعاملة موجودة حاليًا ، يتم إنشاء معاملة لتشغيلها كمعاملة متداخلة للمعاملة الحالية ؛ إذا لم يكن هناك معاملة ، فإن القيمة تعادل المعاملة.

مهلة المعاملات

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

الإعداد الافتراضي هو قيمة المهلة لنظام المعاملات الأساسي. إذا لم يحدد نظام معاملات قاعدة البيانات الأساسي قيمة المهلة ، فهذا لا شيء ، ولا يوجد حد لتهوية.

سمات القراءة فقط

يتم استخدام المعاملات القراءة فقط في المواقف التي يكون فيها رمز العميل للقراءة فقط ولكنه لا يعدل البيانات. يتم استخدام المعاملات القراءة فقط في التحسين في سيناريوهات محددة ، مثل عند استخدام السبات.

الافتراضي هو قراءة وكتابة المعاملات.

قواعد تراجع معاملة الربيع

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

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

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

يمكنك أيضًا استخدام طريقة setRollbackOnly () بشكل برمجي للإشارة إلى أنه يجب التراجع عن المعاملة. الشيء الوحيد الذي يمكنك القيام به بعد استدعاء setRollbackOnly () هو التراجع.

التعليق التوضيحي transactional

خصائص transactional

الاستخدام

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

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

بشكل افتراضي ، سيتم التقاط مكالمات الطريقة فقط من الخارج بواسطة وكيل AOP ، أي أن استدعاء طرق أخرى داخل هذه الفئة داخل الفصل لن يتسبب في سلوك المعاملة ، حتى لو تم تعديل الطريقة المدعوين باستخدام التعليق التوضيحي transactional.

 transactional (readOnly = true) فئة عامة defaultfoOservice تنفذ fooservice {public foo getfoo (String fooname) {// افعل شيئًا} updatefoo (foo foo) {// افعل شيئًا}}

لخص

ما سبق هو كل محتوى تفسير هذه المقالة لاستخدام التعليق التوضيحي transactional في الربيع ، وآمل أن يكون ذلك مفيدًا للجميع. يمكن للأصدقاء المهتمين الاستمرار في الرجوع إلى الموضوعات الأخرى ذات الصلة على هذا الموقع. إذا كانت هناك أي أوجه قصور ، فيرجى ترك رسالة لإشارةها. شكرا لك يا أصدقائك لدعمكم لهذا الموقع!