مقدمة
يحدد الربيع 7 أنواع من سلوكيات انتشار المعاملات في واجهة المعاملة. سلوك انتشار المعاملات هو ميزة تعزيز المعاملات الفريدة في إطار الربيع ، ولا ينتمي إلى سلوك قاعدة البيانات للمزود الفعلي للمعاملة. هذا هو صندوق أدوات قوي يوفر لنا Spring ، ويمكن أن يوفر استخدام خطوط انتشار المعاملات العديد من وسائل الراحة لجهود التطوير لدينا. لكن الناس لديهم الكثير من سوء الفهم حول هذا الموضوع ، ويجب أن تكون قد سمعت الشائعات بأن "طريقة وسيلة الخدمة من الأفضل ألا تكون متداخلة". لاستخدام الأدوات بشكل صحيح ، يجب أولاً فهم الأدوات. تقدم هذه المقالة سلوكيات انتشار المعاملات السبعة بالتفصيل ، وتقدم أمثلة الكود الرئيسي للمحتوى.
المفاهيم الأساسية
1. ما هو سلوك اتصال المعاملات؟
يتم استخدام سلوك انتشار المعاملات لوصف كيفية نشر المعاملات عندما يتم تعديل الأساليب التي يتم تعديلها عن طريق سلوك انتشار المعاملات إلى طريقة أخرى.
استخدم الرمز الزائف لشرح:
public void methoda () {methodb () ؛ // dosomething} transactaction (الانتشار = xxx) methodbure public publicb () {// dosomething} تستدعي طريقة methodA() في الكود طريقة methodB() في المتداخلة ، ويتم تحديد سلوك انتشار المعاملات لـ methodB() عن طريق إعداد @Transaction(Propagation=XXX) . تجدر الإشارة هنا إلى أن methodA() لا تبدأ المعاملة ، ولا يجب استدعاء طريقة تعديل سلوك انتشار المعاملات في الطريقة المحيطية لبدء المعاملة.
2. سبع سلوكيات انتشار المعاملات في الربيع
| نوع سلوك انتشار المعاملات | يوضح |
|---|---|
| spercation_required | إذا لم تكن هناك معاملة في الوقت الحاضر ، فقم بإنشاء معاملة جديدة ، وإذا كانت هناك بالفعل معاملة ، فأضفها إلى المعاملة. هذا هو الخيار الأكثر شيوعا. |
| spercation_supports | يدعم المعاملة الحالية ، وإذا لم يكن هناك معاملة حاليًا ، فسيتم تنفيذها بطريقة غير ناتجة. |
| الانتشار | استخدم المعاملة الحالية ورمي استثناءً إذا لم يكن هناك معاملة حاليًا. |
| spection_requires_new | إنشاء معاملة جديدة. إذا كانت الصفقة موجودة حاليًا ، فقم بتعليق المعاملة الحالية. |
| spection_not_supported | تنفيذ العمليات بطريقة غير محطمة ، وإذا كانت المعاملة موجودة حاليًا ، فسيتم تعليق المعاملة الحالية. |
| الانتشار | ينفذ بطريقة غير محطمة ، ويلقي استثناء في حالة وجود معاملة حاليًا. |
| الانتشار | في حالة وجود صفقة حاليًا ، يتم تنفيذها ضمن معاملة متداخلة. إذا لم تكن هناك معاملة حاليًا ، فقم بإجراء عملية مشابهة لـ Expression_required. |
التعريف بسيط للغاية وسهل الفهم. دعنا نذهب إلى قسم اختبار التعليمات البرمجية للتحقق مما إذا كان فهمنا صحيحًا.
التحقق من الكود
يتم تقديم الرمز في هذه المقالة في طبقتين في بنية ثلاث طبقات تقليدية ، وهما الخدمة وطبقة 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 | تم إدخال "Zhang San" و "Li Si". | لم تبدأ الطريقة المحيطية المعاملة ، وإدراج أساليب "Zhang San" و "Li Si" تعمل بشكل مستقل في معاملاتهم الخاصة. لا تؤثر الطريقة المحيطية غير الطبيعية على الإدراج الداخلي لطرق "Zhang San" و "Li Si". |
| 2 | تم إدخال "Zhang San" ، ولكن لم يتم إدخال "Li Si". | لا تحتوي الطريقة المحيطية على معاملات ، وستقوم كل من طرق إدخال "Zhang San" و "Li Si" بشكل مستقل في معاملاتهما الخاصة ، لذا فإن إدراج "Li Si" لن يتأثر سوى طريقة "Li Si" ، وإدراج "Zhang San" لن يتأثر. |
الخلاصة: من خلال هاتين الطريقتين ، نثبت أن الطريقة الداخلية المعدلة عن طريق الانتشار سيفتح حديثًا معاملاتها الخاصة عندما لا تفتح الطريقة المحيطية المعاملة ، وأن المعاملات المفتوحة مستقلة عن بعضها البعض ولا تتداخل مع بعضها البعض.
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") ؛ }}تنفيذ طرق التحقق بشكل منفصل ، والنتائج:
| الرقم التسلسلي طريقة التحقق | نتائج قاعدة البيانات | تحليل النتائج |
|---|---|---|
| 1 | لم يتم إدخال "Zhang San" و "Li Si". | تبدأ الطريقة المحيطية في المعاملة ، وتنضم الطريقة الداخلية إلى معاملة الطريقة المحيطية ، والطريقة المحيطية تراجع ، ويجب التراجع عن الطريقة الداخلية أيضًا. |
| 2 | لم يتم إدخال "Zhang San" و "Li Si". | تفتح الطريقة المحيطية المعاملة ، وتضيف الطريقة الداخلية معاملة الطريقة المحيطية ، والأسلوب الداخلي يلقي تراجعًا استثناءً ، وتدرك الطريقة المحيطية الاستثناء الذي تسبب في التراجع الكلي للمعاملة. |
| 3 | لم يتم إدخال "Zhang San" و "Li Si". | تفتح الطريقة المحيطية المعاملة ، وتنضم الطريقة الداخلية إلى معاملة الطريقة المحيطية ، وتلقي الطريقة الداخلية تراجعًا استثناءً. حتى إذا تم اكتشاف الطريقة ولم يتم إدراكها بالطريقة المحيطية ، فإن المعاملة بأكملها لا تزال تراجع. |
الخلاصة: تبين النتائج التجريبية أعلاه أنه عندما تفتح الطريقة المحيطية المعاملة ، ستتم إضافة الطرق الداخلية المعدلة عن طريق 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) ؛ }تنفيذ طرق التحقق بشكل منفصل ، والنتائج:
| الرقم التسلسلي طريقة التحقق | نتائج قاعدة البيانات | تحليل النتائج |
|---|---|---|
| 1 | تم إدخال "Zhang San" ، و "Li Si" مدرج. | الطريقة المحيطية ليس لها معاملات. يتم إدخال أساليب "Zhang San" و "Li Si" بشكل مستقل في معاملاتهم الخاصة. لن يؤثر تراجع الاستثناء للطريقة المحيطية على الطريقة الداخلية. |
| 2 | تم إدخال "Zhang San" ، "Li Si" لم يتم إدخاله | الطريقة المحيطية لا تبدأ المعاملة. يبدأ إدخال طريقة "Zhang San" وإدخال طريقة "Li Si" معاملاتهم الخاصة على التوالي. إدراج طريقة "li si" يلقي تراجعًا استثناءً ، ولا تتأثر المعاملات الأخرى. |
الخلاصة: من خلال هاتين الطريقتين ، نثبت أن الطريقة الداخلية المعدلة عن طريق 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") ؛ }}تنفيذ طرق التحقق بشكل منفصل ، والنتائج:
| الرقم التسلسلي طريقة التحقق | نتائج قاعدة البيانات | تحليل النتائج |
|---|---|---|
| 1 | لم يتم إدخال "Zhang San" ، وتم إدخال "Li Si" ، وتم إدخال "Wang Wu". | تبدأ الطريقة المحيطية المعاملة ، وتدرج معاملة من طريقة "Zhang San" والطريقة المحيطية ، وإدراج طريقة "Li Si" وطريقة "Wang WU" على التوالي في المعاملة المستقلة التي تم إنشاؤها حديثًا. ترمي الطريقة المحيطية استثناءً وتدحرج فقط نفس المعاملة مثل الطريقة المحيطية ، وبالتالي فإن طريقة إدراج طريقة "Zhang San" تراجع. |
| 2 | لم يتم إدخال "Zhang San" ، وتم إدخال "Li Si" ، ولم يتم إدخال "Wang Wu". | تبدأ الطريقة المحيطية المعاملة ، وتدرج معاملة من طريقة "Zhang San" والطريقة المحيطية ، وإدراج طريقة "Li Si" وطريقة "Wang WU" في المعاملات الجديدة المستقلة. عند إدراج طريقة "Wang Wu" ، يتم التراجع عن المعاملة التي يتم إدراجها في طريقة "Wang Wu". يستمر الاستثناء في إلقاؤه ويتم إدراكه بالطريقة المحيطية. يتم أيضًا التراجع عن معاملة الطريقة المحيطية ، لذلك يتم التراجع عن طريقة "Zhang San" أيضًا. |
| 3 | تم إدخال "Zhang San" ، "Li Si" تم إدخاله ، و "Wang Wu" لم يتم إدخاله. | تبدأ الطريقة المحيطية المعاملة ، وتدرج معاملة من طريقة "Zhang San" والطريقة المحيطية ، وإدراج طريقة "Li Si" وطريقة "Wang WU" في المعاملات الجديدة المستقلة. يتم إدخال طريقة "Wang Wu" وتم تراجع المعاملة التي تدرج طريقة "Wang Wu". يتم اكتشاف الاستثناء ولن يتم إدراكه بالطريقة المحيطية. لا يتم التراجع عن معاملة الطريقة المحيطية ، وبالتالي يتم إدخال إدخال طريقة "Zhang San" بنجاح. |
الخلاصة: عندما تفتح الطريقة المحيطية المعاملة ، فإن الطريقة الداخلية المعدلة بواسطة 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) ؛ }تنفيذ طرق التحقق بشكل منفصل ، والنتائج:
| الرقم التسلسلي طريقة التحقق | نتائج قاعدة البيانات | تحليل النتائج |
|---|---|---|
| 1 | تم إدخال "Zhang San" و "Li Si". | لم تبدأ الطريقة المحيطية المعاملة ، وإدراج أساليب "Zhang San" و "Li Si" تعمل بشكل مستقل في معاملاتهم الخاصة. لا تؤثر الطريقة المحيطية غير الطبيعية على الإدراج الداخلي لطرق "Zhang San" و "Li Si". |
| 2 | تم إدخال "Zhang San" ، ولكن لم يتم إدخال "Li Si". | لا تحتوي الطريقة المحيطية على معاملات ، وستقوم كل من طرق إدخال "Zhang San" و "Li Si" بشكل مستقل في معاملاتهما الخاصة ، لذا فإن إدراج "Li Si" لن يتأثر سوى طريقة "Li Si" ، وإدراج "Zhang San" لن يتأثر. |
الخلاصة: من خلال هاتين الطريقتين ، نثبت أن 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") ؛ }}تنفيذ طرق التحقق بشكل منفصل ، والنتائج:
| الرقم التسلسلي طريقة التحقق | نتائج قاعدة البيانات | تحليل النتائج |
|---|---|---|
| 1 | لم يتم إدخال "Zhang San" و "Li Si". | تبدأ الطريقة المحيطية المعاملة ، والمعاملة الداخلية هي عملية فرعية للمعاملة المحيطية. تتراجع الطريقة المحيطية ، ويجب التراجع عن الطريقة الداخلية أيضًا. |
| 2 | لم يتم إدخال "Zhang San" و "Li Si". | تبدأ الطريقة المحيطية المعاملة ، والمعاملة الداخلية هي عملية فرعية للمعاملة المحيطية. تطرح الطريقة الداخلية تراجعًا استثناءً ، وتدرك الطريقة المحيطية الاستثناء الذي تسبب في تراجع المعاملة الكلية. |
| 3 | تم إدخال "Zhang San" ، و "Li Si" لم يتم إدخاله. | تبدأ الطريقة المحيطية المعاملة ، والمعاملة الداخلية هي عملية فرعية للمعاملة المحيطية. أدخل الطريقة الداخلية "Zhang San" لرمي استثناء ، ويمكن التراجع عن معاملة الطفل بشكل منفصل. |
الخلاصة: تبين نتائج الاختبار أعلاه أنه عندما تفتح الطريقة المحيطية المعاملة ، فإن الطريقة الداخلية المعدلة عن طريق 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.