Rumah >Java >javaTutorial >Bila dan Mengapa Anda Perlu Laraskan Parameter Pengasingan dan Penyebaran Lalai dalam @Transactional?

Bila dan Mengapa Anda Perlu Laraskan Parameter Pengasingan dan Penyebaran Lalai dalam @Transactional?

DDD
DDDasal
2024-11-03 19:56:02712semak imbas

When and Why Should You Adjust the Default Isolation and Propagation Parameters in @Transactional?

Parameter Pengasingan dan Penyebaran dalam @Transactional

Dalam anotasi @Transactional Spring, dua parameter kritikal mentakrifkan gelagat transaksi pangkalan data: pengasingan dan penyebaran . Artikel ini meneroka bila dan sebab anda perlu mempertimbangkan untuk melaraskan nilai lalainya.

Penyebaran

Penyebaran mentakrifkan cara transaksi berkaitan antara satu sama lain. Pilihan biasa termasuk:

  • DIPERLUKAN: Menjalankan kod dalam transaksi sedia ada atau mencipta yang baharu jika tiada.
  • MEMERLUKAN_BARU: Sentiasa mencipta transaksi baharu, menggantung mana-mana transaksi sedia ada.

Nilai Lalai: DIPERLUKAN

Pengasingan

Pengasingan mentakrifkan kontrak data antara transaksi. Ia menghalang ketidakkonsistenan data tertentu dengan menyatakan tahap keterlihatan ke dalam perubahan data yang dibuat oleh transaksi lain. Tahap pengasingan utama ialah:

  • READ_UNCOMMITTED: Tiada perlindungan terhadap bacaan kotor.
  • SERIALIZED: Pengasingan terkuat, memastikan tiada konflik data.

Nilai Lalai: Berbeza-beza bergantung pada pangkalan data (cth., REPEATABLE_READ untuk MariaDB)

Contoh Dunia Sebenar

Pertimbangkan isu bacaan kotor, di mana transaksi boleh membaca perubahan tanpa komitmen yang dibuat oleh transaksi lain.

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

Dalam senario ini, untuk mengelakkan bacaan kotor, anda boleh menetapkan tahap pengasingan kepada READ_COMMITTED dan tahap penyebaran kepada DIPERLUKAN. Gabungan ini memastikan transaksi hanya membaca data yang telah dilakukan oleh transaksi lain.

Menyesuaikan Transaksi

Dalam contoh berikut, kaedah provideService sentiasa berjalan dalam transaksi baharu, memastikan bahawa sebarang perubahan yang dibuat oleh tugas serentak lain tidak mengganggu pelaksanaannya:

<code class="java">@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}</code>

Menguji Tingkah Laku Transaksi

Untuk mengesahkan tingkah laku tahap penyebaran yang berbeza, anda boleh menggunakan ujian Java:

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

Dengan REQUIRES_NEW, fooService.provideService() tidak akan ditarik balik sejak ia beroperasi dalam urus niaga yang berasingan. Dengan DIPERLUKAN, semuanya akan ditarik balik.

Atas ialah kandungan terperinci Bila dan Mengapa Anda Perlu Laraskan Parameter Pengasingan dan Penyebaran Lalai dalam @Transactional?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn