معلمات العزل والنشر في @Transactional

في شرح Spring's @Transactional، تحدد معلمتان مهمتان سلوك معاملات قاعدة البيانات: العزل والنشر . تستكشف هذه المقالة متى ولماذا يجب أن تفكر في تعديل قيمها الافتراضية.

النشر

يحدد النشر كيفية ارتباط المعاملات ببعضها البعض. تتضمن الخيارات الشائعة ما يلي:

• المطلوب: تشغيل الرمز ضمن معاملة موجودة أو إنشاء معاملة جديدة في حالة عدم وجودها.
• REQUIRES_NEW: يقوم دائمًا بإنشاء معاملة جديدة، وتعليق أي معاملات موجودة.

القيمة الافتراضية: مطلوبة

العزل

يحدد العزل عقد البيانات بين المعاملات. فهو يمنع بعض حالات عدم تناسق البيانات عن طريق تحديد مستوى الرؤية لتغييرات البيانات التي تتم بواسطة المعاملات الأخرى. مستويات العزل الرئيسية هي:

• READ_UNCOMMITTED: لا توجد حماية ضد القراءات القذرة.
• قابل للتسلسل: أقوى عزل، مما يضمن عدم وجود تعارض في البيانات.

القيمة الافتراضية: تختلف حسب قاعدة البيانات (على سبيل المثال، REPEATABLE_READ لـ MariaDB)

مثال من العالم الحقيقي

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

الموضوع 1 الموضوع 2 | | اكتب(س) | | | | قراءة (خ) | | التراجع | | | القيمة (x) أصبحت الآن متسخة (غير صحيحة)

                                       Thread 1          Thread 2
                                               |              |
                                             Write(x)           |
                                               |              |
                                               |             Read(x)
                                               |              |
                                             Rollback           |
                                                 |             |
                                                   Value (x) is now dirty (incorrect)

في هذا السيناريو، لمنع القراءات المتسخة، يمكنك تعيين مستوى العزل إلى

READ_COMMITTED ومستوى النشر إلى مطلوب. تضمن هذه المجموعة أن المعاملات تقرأ فقط البيانات التي تم الالتزام بها من خلال معاملات أخرى.

تخصيص المعاملات

في المثال التالي، طريقة

provideService يتم تشغيله دائمًا ضمن معاملة جديدة، مما يضمن أن أي تغييرات يتم إجراؤها بواسطة المهام المتزامنة الأخرى لا تتداخل مع تنفيذها:

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}

اختبار سلوك المعاملة

للتحقق من سلوك مستويات الانتشار المختلفة، يمكنك استخدام اختبار Java:

@Test
public void testProvideService() {
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
    fooService.provideService();
    transactionManager.rollback(status);
    // Assert repository values are unchanged ...
}

مع

REQUIRES_NEW، لن يتم التراجع عن fooService.provideService() نظرًا لأنه يعمل ضمن معاملة منفصلة. باستخدام REQUIRED، سيتم التراجع عن كل شيء.