افهم بعمق سلوك انتشار معاملات الربيع

مقدمة

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

المفاهيم الأساسية

1. ما هو سلوك اتصال المعاملات؟

يتم استخدام سلوك انتشار المعاملات لوصف كيفية نشر المعاملات عندما يتم تعديل الأساليب التي يتم تعديلها عن طريق سلوك انتشار المعاملات إلى طريقة أخرى.

استخدم الرمز الزائف لشرح:

 public void methoda () {methodb () ؛ // dosomething} transactaction (الانتشار = xxx) methodbure public publicb () {// dosomething}

تستدعي طريقة methodA() في الكود طريقة methodB() في المتداخلة ، ويتم تحديد سلوك انتشار المعاملات لـ methodB() عن طريق إعداد @Transaction(Propagation=XXX) . تجدر الإشارة هنا إلى أن methodA() لا تبدأ المعاملة ، ولا يجب استدعاء طريقة تعديل سلوك انتشار المعاملات في الطريقة المحيطية لبدء المعاملة.

2. سبع سلوكيات انتشار المعاملات في الربيع

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

التحقق من الكود

يتم تقديم الرمز في هذه المقالة في طبقتين في بنية ثلاث طبقات تقليدية ، وهما الخدمة وطبقة DAO. الربيع مسؤول عن حقن التبعية وإدارة معاملات التعليقات التوضيحية. يتم تنفيذ طبقة DAO بواسطة MyBatis. يمكنك أيضًا استخدام أي طريقة مفضلة ، مثل Hibernate و JPA و JDBCtemplate ، وما إلى ذلك. تستخدم قاعدة البيانات قاعدة بيانات MySQL ، ويمكنك أيضًا استخدام أي قاعدة بيانات تدعم المعاملة ، والتي لن تؤثر على نتائج التحقق.

أولاً نقوم بإنشاء جدولين في قاعدة البيانات:

user1

 قم بإنشاء جدول `user1` (` id 'integer غير موقّع وليس null auto_increment ، `name` varchar (45) وليس الافتراضي الفارغ" ، المفتاح الأساسي (`id`)) المحرك = innodb ؛

user2

 قم بإنشاء جدول `user2` (` `id` integer غير موقعة وليس null auto_increment ، `name` varchar (45) غير فارغ" ، المفتاح الأساسي (`id`)) المحرك = innodb ؛

ثم اكتب رمز طبقة الفاصوليا و DAO المقابلة:

user1

 الفئة العامة user1 {private integer id ؛ اسم السلسلة الخاصة ؛ // الحصول على الأساليب المحذوفة ...}

user2

 الفئة العامة user2 {private integer id ؛ اسم السلسلة الخاصة ؛ // الحصول على الأساليب المحذوفة ...}

user1mapper

 الواجهة العامة user1mapper {int insert (user1 record) ؛ user1 selectByPrimaryKey (INTEGER ID) ؛ // تم حذف طرق أخرى ...}

user2mapper

 واجهة عامة user2mapper {int insert (user2 record) ؛ user2 selectByPrimaryKey (INTEGER ID) ؛ // تم حذف طرق أخرى ...}

أخيرًا ، يتم تنفيذ رمز التحقق المحدد بواسطة طبقة الخدمة ، وسنسره في المواقف التالية.

1.propagation_required

نضيف Propagation.REQUIRED السمات المطلوبة إلى الطرق المقابلة لـ user1service و user2service.

طريقة خدمة user1:

 servicepublic class user1ServiceImpl تنفذ user1service {// حذف الآخرين ... OverrideTransActional (spection.required) public void addRequired (user1 user) {user1mapper.insert (user) ؛ }}

طريقة خدمة user2:

 servicepublic class user2ServiceImpl تنفذ user2service {// حذف الآخرين ... OverRideTransActional (spection.required) public void addRequired (user2 user) {user2mapper.insert (user) ؛ } OverRideTransActional (الانتشار = الانتشار. رمي new RunTimeException () ؛ }}

1.1 المشهد 1

هذه الطريقة السيناريو الطرفية لا تمكن المعاملات.

طريقة التحقق 1:

 Override public void nottransaction_exception_required_required () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.AddRequired (user2) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 Override public void nottransaction_required_required_exception () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiredException (user2) ؛ }

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

تحليل نتائج قاعدة التحقق من الأرقام التسلسلية

الخلاصة: من خلال هاتين الطريقتين ، نثبت أن الطريقة الداخلية المعدلة عن طريق الانتشار سيفتح حديثًا معاملاتها الخاصة عندما لا تفتح الطريقة المحيطية المعاملة ، وأن المعاملات المفتوحة مستقلة عن بعضها البعض ولا تتداخل مع بعضها البعض.

1.2 المشهد 2

تبدأ الطريقة المحيطية المعاملة ، وهي سيناريو مع معدل استخدام مرتفع نسبيًا.

طريقة التحقق 1:

 OverRideTransActional (الانتشار = الانتشار. user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.AddRequired (user2) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 OverRideTransActional (الانتشار = الانتشار. user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiredException (user2) ؛ }

طريقة التحقق 3:

 TransActionalOverride public void Transaction_required_required_exception_try () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ حاول {user2service.addrequiredException (user2) ؛ } catch (استثناء e) {system.out.println ("Method Rollback") ؛ }}

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

الخلاصة: تبين النتائج التجريبية أعلاه أنه عندما تفتح الطريقة المحيطية المعاملة ، ستتم إضافة الطرق الداخلية المعدلة عن طريق Propagation.REQUIRED . جميع الطرق الداخلية والطرق المحيطية المعدلة عن طريق Propagation.REQUIRED . طالما أن طريقة واحدة تتدحرج ، سيتم تراجع المعاملة بأكملها.

2.propagation_requires_new

نضيف سمة Propagation.REQUIRES_NEW إلى الطرق المقابلة لـ user1service و user2service.

طريقة خدمة user1:

 servicepublic class user1ServiceImpl تنفذ user1service {// حذف الآخرين ... OverrideTransActional (spection.requires_new) public void addRequiresNew (user1 user) {user1mapper.insert (user) ؛ } OverRideTransActional (الانتشار = الانتشار. }}

طريقة خدمة user2:

 servicepublic class user2ServiceImpl تنفذ user2service {// حذف الآخرين ... overridetransactional (spection.requires_new) public void addRequiresNew (user2 user) {user2mapper.insert (user) ؛ } OverRideTransActional (الانتشار = الانتشار. REQUIRES_NEW) public void addrequiresNewException (user2 user) {user2mapper.insert (user) ؛ رمي new RunTimeException () ؛ }}

2.1 المشهد 1

الطريقة المحيطية لا تمكن المعاملات.

طريقة التحقق 1:

 Override public void nottransaction_exception_requiresnew_requiresnew () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addrequiresNew (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiresNew (user2) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 Override public void nottransaction_requiresnew_requiresnew_exception () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addrequiresNew (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.AdDrequiresNewException (user2) ؛ }

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

الخلاصة: من خلال هاتين الطريقتين ، نثبت أن الطريقة الداخلية المعدلة عن طريق Propagation.REQUIRES_NEW ستبدأ requires_new حديثًا معاملاتها الخاصة ، وأن المعاملات المفتوحة مستقلة عن بعضها البعض ولا تتداخل مع بعضها البعض.

2.2 المشهد 2

الطريقة المحيطية تبدأ الصفقة.

طريقة التحقق 1:

 OverRideTransActional (الانتشار = الانتشار. user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiresNew (user2) ؛ user2 user3 = new user2 () ؛ user3.setName ("Wang Wu") ؛ user2Service.addRequiresNew (user3) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 OverRideTransActional (الانتشار = الانتشار. user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiresNew (user2) ؛ user2 user3 = new user2 () ؛ user3.setName ("Wang Wu") ؛ user2Service.AddRequiresNewException (user3) ؛ }

طريقة التحقق 3:

 OverRideTransActional (الانتشار = الانتشار. user1.setName ("Zhang San") ؛ user1service.addrequired (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.addRequiresNew (user2) ؛ user2 user3 = new user2 () ؛ user3.setName ("Wang Wu") ؛ حاول {user2service.addRequiresNewException (user3) ؛ } catch (استثناء e) {system.out.println ("RollingBack") ؛ }}

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

الخلاصة: عندما تفتح الطريقة المحيطية المعاملة ، فإن الطريقة الداخلية المعدلة بواسطة Propagation.REQUIRES_NEW ستظل REQUIRES_NEW تفتح المعاملات المستقلة بشكل منفصل ، وهي أيضًا مستقلة عن معاملات الطريقة الخارجية. الطريقة الداخلية والطريقة الداخلية ومعاملات الطريقة الخارجية مستقلة عن بعضها البعض ولا تتداخل مع بعضها البعض.

3.propagation_nested

نضيف Propagation.NESTED السمات التي تم اختبارها إلى الطرق المقابلة لـ user1service و user2service.

طريقة خدمة user1:

 servicepublic class user1ServiceImpl تنفذ user1service {// حذف الآخرين ... OverrideTransActional (spection.nested) public void addNested (user1 user) {user1mapper.insert (user) ؛ }}

طريقة خدمة user2:

 servicepublic class user2ServiceImpl تنفذ user2service {// حذف الآخرين ... OverRideTransActional (spection.nested) public void addnested (user2 user) {user2mapper.insert (user) ؛ } OverRideTransActional (الانتشار = الانتشار. رمي new RunTimeException () ؛ }}

3.1 المشهد 1

هذه الطريقة السيناريو الطرفية لا تمكن المعاملات.

طريقة التحقق 1:

 Override public void nottransaction_exception_nested_nested () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addnested (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.Addnested (user2) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 Override public void nottransaction_nted_nted_exception () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addnested (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.AdDnedException (user2) ؛ }

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

الخلاصة: من خلال هاتين الطريقتين ، نثبت أن Propagation.NESTED . next and Propagation.REQUIRED لها نفس الوظائف عندما لا تفتح الطريقة المحيطية المعاملة. ستبدأ الطرق الداخلية المعدلة معاملاتها مرة أخرى ، والمعاملات المفتوحة مستقلة عن بعضها البعض ولا تتداخل مع بعضها البعض.

3.2 المشهد 2

الطريقة المحيطية تبدأ الصفقة.

طريقة التحقق 1:

 TransActional Override public void transaction_exception_nested_nested () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addnested (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.Addnested (user2) ؛ رمي new RunTimeException () ؛ }

طريقة التحقق 2:

 TransActionalOverride public void Transactaction_nted_nted_exception () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addnested (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ user2Service.AdDnedException (user2) ؛ }

طريقة التحقق 3:

 transactionaloverride public void Transaction_nted_nted_exception_try () {user1 user1 = new user1 () ؛ user1.setName ("Zhang San") ؛ user1service.addnested (user1) ؛ user2 user2 = new user2 () ؛ user2.setName ("li si") ؛ حاول {user2service.addnestception (user2) ؛ } catch (استثناء e) {system.out.println ("Method Rollback") ؛ }}

تنفيذ طرق التحقق بشكل منفصل ، والنتائج:

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

4. أوجه التشابه وأوجه التشابه بين المطلوبة ، يتطلب _new ، متداخلة

من مقارنة "1.2 المشهد 2" و "3.2 المشهد 2" ، يمكننا أن نرى:

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

من مقارنة "2.2 المشهد 2" و "3.2 المشهد 2" ، يمكننا أن نرى:

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

5. سلوكيات انتشار المعاملات الأخرى

في ضوء قضية طول المقالة ، لن يتم وصف اختبارات سلوكيات انتشار المعاملات الأخرى هنا. يمكن للقراء المهتمين البحث عن رمز الاختبار المقابل وتفسيرات النتائج في الكود المصدري. بوابة: https: //github.com/tmtse/tran ...

حالات استخدام المحاكاة

بعد تقديم العديد من سلوكيات اتصال المعاملات ، كيف يمكننا تطبيقها في عملنا الفعلي؟ دعني أعطيك مثالاً:

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

 service public class orperviceImpl تنفذ المستخدمين {transactional public void register (user user) {try {memberhippointservice.addpoint (point point) ؛ } catch (استثناء e) {// shife ...} // shomit ...} // shife ...}

ننص أيضًا على أن فشل التسجيل سيؤثر على طريقة addPoint() (تراجع طريقة التسجيل يتطلب أيضًا تراجعًا) ، لذلك يجب تنفيذ طريقة addPoint() مثل هذا:

 Service Public Class BegghenshippointServiceImpl تنفذ الأعضاء hippointservice {transactional (spection.ned) public void addPoint (point point) {try {recordervice.addrecord (سجل السجل) ؛ } catch (استثناء e) {// shife ...} // shomit ...} // shife ...}

لاحظنا أن طريقة addRecord() addPoint() ، والتي تستخدم لتسجيل السجلات. تنفيذه على النحو التالي:

 Service Public Class RecordserviceImpl تنفذ Recordservice {transactional (الانتشار = الانتشار

لاحظنا propagation = Propagation.NOT_SUPPORTED في طريقة addRecord() ، لأنها ليست دقيقة للسجل ، ويمكن أن يكون المرء أكثر أو أقل ، وبالتالي فإن طريقة addRecord() لن تؤثر على طريقة addRecord() لنفاع addPoint() addRecord() الطرفية addPoint() .

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

ختاماً

من خلال المقدمة أعلاه ، أعتقد أن كل شخص لديه فهم أعمق لسلوك التواصل مع معاملات الربيع ، وآمل أن يكون عمل التنمية اليومي مفيدًا.

لخص

ما سبق هو المحتوى الكامل لهذه المقالة. آمل أن يكون لمحتوى هذه المقالة قيمة مرجعية معينة لدراسة أو عمل الجميع. إذا كان لديك أي أسئلة ، فيمكنك ترك رسالة للتواصل. شكرا لك على دعمك إلى wulin.com.