Sangat memahami perilaku propagasi transaksi musim semi

Kata pengantar

Spring menentukan 7 jenis perilaku propagasi transaksi dalam antarmuka definisi transaksi. Perilaku propagasi transaksi adalah fitur peningkatan transaksi yang unik untuk kerangka kerja musim semi, dan itu bukan milik perilaku basis data dari penyedia aktual transaksi. Ini adalah kotak alat yang kuat yang disediakan Spring kepada kita, dan menggunakan jalur perambatan transaksi dapat memberikan banyak kenyamanan untuk upaya pengembangan kita. Tetapi orang -orang memiliki banyak kesalahpahaman tentang hal itu, dan Anda pasti telah mendengar desas -desus bahwa "bisnis metode layanan terbaik untuk tidak bersarang." Untuk menggunakan alat dengan benar, Anda harus terlebih dahulu memahami alat. Artikel ini memperkenalkan tujuh perilaku propagasi transaksi secara rinci, dan menyajikan contoh kode utama konten.

Konsep Dasar

1. Apa itu perilaku komunikasi transaksi?

Perilaku perambatan transaksi digunakan untuk menggambarkan bagaimana transaksi disebarkan ketika metode yang dimodifikasi oleh perilaku perambatan transaksi tertentu bersarang menjadi metode lain.

Gunakan pseudo-code untuk menjelaskan:

 public void methoda () {MethodB (); // dosomething} @transaction (propagation = xxx) public void MethodB () {// dosomething}

Metode methodA() dalam kode memanggil metode methodB() dalam bersarang, dan perilaku propagasi transaksi methodB() ditentukan oleh pengaturan @Transaction(Propagation=XXX) . Perlu dicatat di sini bahwa methodA() tidak memulai transaksi, dan metode memodifikasi perilaku perambatan transaksi tertentu tidak harus dipanggil dalam metode perifer untuk memulai transaksi.

2. Tujuh Perilaku Propagasi Transaksi di Musim Semi

Definisi ini sangat sederhana dan mudah dimengerti. Mari kita pergi ke bagian uji kode untuk memverifikasi apakah pemahaman kita benar.

Verifikasi Kode

Kode dalam artikel ini disajikan dalam dua lapisan dalam struktur tiga lapis tradisional, yaitu layanan dan lapisan DAO. Musim semi bertanggung jawab atas manajemen transaksi injeksi dan anotasi ketergantungan. Lapisan DAO diimplementasikan oleh Mybatis. Anda juga dapat menggunakan metode favorit apa pun, seperti Hibernate, JPA, JDBCtemplate, dll. Basis data menggunakan database MySQL, dan Anda juga dapat menggunakan database yang diaktifkan transaksi, yang tidak akan mempengaruhi hasil verifikasi.

Pertama kami membuat dua tabel di database:

user1

 Buat tabel `user1` (` id` integer unsigned not null auto_increment, `name` varchar (45) bukan null default '', kunci utama (` id`)) engine = innodb;

user2

 Buat tabel `user2` (` id` integer unsigned not null auto_increment, `name` varchar (45) bukan null default '', kunci utama (` id`)) engine = innodb;

Kemudian tulis kode lapisan kacang dan dao yang sesuai:

User1

 Public Class User1 {Private Integer ID; nama string pribadi; // Dapatkan dan mengatur metode dihilangkan ...}

User2

 Public Class User2 {Private Integer ID; nama string pribadi; // Dapatkan dan mengatur metode dihilangkan ...}

User1mapper

 antarmuka publik user1mapper {int insert (catatan user1); User1 selectbyprimarykey (integer id); // metode lain dihilangkan ...}

User2mapper

 antarmuka publik user2mapper {int insert (user2 record); User2 SelectByPrimaryKey (ID Integer); // metode lain dihilangkan ...}

Akhirnya, kode verifikasi spesifik diimplementasikan oleh lapisan layanan, dan kami akan mencantumkannya dalam situasi berikut.

1.propagation_required

Kami menambahkan Propagation.REQUIRED Atribut yang diperlukan ke metode yang sesuai dari User1Service dan User2Service.

Metode User1Service:

 @ServicePublic kelas user1ServiceImpl mengimplementasikan user1service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.Required) public void addrequired (user1 user) {user1mapper.insert (user); }}

Metode User2Service:

 @ServicePublic kelas User2ServiceImpl mengimplementasikan user2service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.Required) public void addRequired (user2 user) {user2mapper.insert (user); } @Override @transactional (propagation = propagation.equired) public void addRequiredException (user2 user) {user2mapper.insert (user); lempar runimeException baru (); }}

1.1 Adegan 1

Metode periferal skenario ini tidak memungkinkan transaksi.

Metode Verifikasi 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); lempar runimeException baru (); }

Metode Verifikasi 2:

 @Override public void nottransaction_required_required_exception () {user1 user1 = User1 baru1 (); user1.setname ("Zhang San"); user1service.addrequired (user1); User2 user2 = new user2 (); user2.setname ("li si"); user2service.addrequiredException (user2); }

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Analisis Hasil Metode Verifikasi Basis Data Nomor Seri

Kesimpulan: Melalui dua metode ini, kami membuktikan bahwa metode internal yang dimodifikasi dengan propagasi. Permintaan akan baru saja membuka transaksi sendiri ketika metode periferal tidak membuka transaksi, dan transaksi yang dibuka tidak tergantung satu sama lain dan tidak saling mengganggu.

1.2 Adegan 2

Metode periferal memulai transaksi, yang merupakan skenario dengan tingkat penggunaan yang relatif tinggi.

Metode Verifikasi 1:

 @Override @Transactional (propagation = propagation.Required) public void transaction_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); lempar runimeException baru (); }

Metode Verifikasi 2:

 @Override @transactional (propagation = propagation.Required) public void transaction_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); }

Metode Verifikasi 3:

 @Transactional @Override public void transaction_required_required_exception_try () {user1 user1 = User1 baru1 (); user1.setname ("Zhang San"); user1service.addrequired (user1); User2 user2 = new user2 (); user2.setname ("li si"); coba {user2service.addRequiredException (user2); } catch (Exception e) {System.out.println ("Metode Rollback"); }}

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Kesimpulan: Hasil eksperimen di atas menunjukkan bahwa ketika metode periferal membuka transaksi, metode internal yang dimodifikasi oleh Propagation.REQUIRED akan ditambahkan ke transaksi metode perifer. Semua metode internal dan metode periferal yang dimodifikasi oleh Propagation.REQUIRED termasuk dalam transaksi yang sama. Selama satu metode bergulir kembali, seluruh transaksi akan digulung kembali.

2.propagation_requires_new

Kami menambahkan atribut Propagation.REQUIRES_NEW ke metode yang sesuai dari User1Service dan User2Service.

Metode User1Service:

 @ServicePublic kelas user1serviceImpl mengimplementasikan user1service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.requires_new) public void addrequiresnew (user1 user) {user1mapper.insert (user); } @Override @transactional (propagation = propagation.Required) public void addRequired (user1 user) {user1mapper.insert (user); }}

Metode User2Service:

 @ServicePublic kelas User2ServiceImpl mengimplementasikan user2service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.requires_new) public void addrequiresnew (user2 user) {user2mapper.insert (user); } @Override @transactional (propagation = propagation.requires_new) public void addRequiresNewException (user2 user) {user2mapper.insert (user); lempar runimeException baru (); }}

2.1 Adegan 1

Metode periferal tidak memungkinkan transaksi.

Metode Verifikasi 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); lempar runimeException baru (); }

Metode Verifikasi 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); }

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Kesimpulan: Melalui kedua metode ini, kami membuktikan bahwa metode internal yang dimodifikasi oleh Propagation.REQUIRES_NEW

2.2 Adegan 2

Metode periferal memulai transaksi.

Metode Verifikasi 1:

 @Override @Transactional (propagation = propagation.Required) public void transaction_exception_required_requiresnew_requiresnew () {user1 user1 = User1 baru1 (); 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); lempar runimeException baru (); }

Metode Verifikasi 2:

 @Override @Transactional (propagation = propagation.required) public void transaction_required_requiresnew_requiresnew_exception () {user1 user1 = User1 baru1 (); 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); }

Metode Verifikasi 3:

 @Override @Transactional (propagation = propagation.required) public void transaction_required_requiresnew_requiresnew_exception_try () {user1 user1 = User1 baru1 (); 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"); coba {user2service.addRequiresNewException (user3); } catch (Exception e) {System.out.println ("rollingback"); }}

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Kesimpulan: Ketika metode periferal membuka transaksi, metode internal yang dimodifikasi oleh Propagation.REQUIRES_NEW . Metode internal, metode internal dan transaksi metode eksternal tidak tergantung satu sama lain dan tidak saling mengganggu.

3.propagation_nested

Kami menambahkan Propagation.NESTED Atribut yang Diperhatikan ke metode yang sesuai dari User1Service dan User2Service.

Metode User1Service:

 @ServicePublic kelas user1serviceImpl mengimplementasikan user1service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.nested) public void addnested (user1 user1) {user1mapper.insert (user); }}

Metode User2Service:

 @ServicePublic kelas User2ServiceImpl mengimplementasikan user2service {// hilangkan lainnya ... @Override @transactional (propagation = propagation.nested) public void addnested (user2 user) {user2mapper.insert (user); } @Override @transactional (propagation = propagation.nested) public void addnestedException (user2 user) {user2mapper.insert (user); lempar runimeException baru (); }}

3.1 Adegan 1

Metode periferal skenario ini tidak memungkinkan transaksi.

Metode Verifikasi 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); lempar runimeException baru (); }

Metode Verifikasi 2:

 @Override public void nottransaction_nested_nested_exception () {user1 user1 = new user1 (); user1.setname ("Zhang San"); user1service.addnested (user1); User2 user2 = new user2 (); user2.setname ("li si"); user2service.addnestedException (user2); }

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Kesimpulan: Melalui dua metode ini, kami membuktikan bahwa Propagation.NESTED dan Propagation.REQUIRED Perlu memiliki fungsi yang sama ketika metode periferal tidak membuka transaksi. Metode internal yang dimodifikasi akan memulai transaksi mereka sendiri lagi, dan transaksi yang dibuka tidak tergantung satu sama lain dan tidak saling mengganggu.

3.2 Adegan 2

Metode periferal memulai transaksi.

Metode Verifikasi 1:

 @Transactional @Override public void transaction_exception_nested_nested () {user1 user1 = User1 baru1 (); user1.setname ("Zhang San"); user1service.addnested (user1); User2 user2 = new user2 (); user2.setname ("li si"); user2service.addnested (user2); lempar runimeException baru (); }

Metode Verifikasi 2:

 @Transactional @Override public void transaction_nested_nested_exception () {user1 user1 = User1 baru1 (); user1.setname ("Zhang San"); user1service.addnested (user1); User2 user2 = new user2 (); user2.setname ("li si"); user2service.addnestedException (user2); }

Metode Verifikasi 3:

 @Transactional @Override public void transaction_nested_nested_exception_try () {user1 user1 = new user1 (); user1.setname ("Zhang San"); user1service.addnested (user1); User2 user2 = new user2 (); user2.setname ("li si"); coba {user2service.addnestedException (user2); } catch (Exception e) {System.out.println ("Metode Rollback"); }}

Jalankan metode verifikasi secara terpisah, dan hasilnya:

Kesimpulan: Hasil tes di atas menunjukkan bahwa ketika metode perifer membuka transaksi, metode internal yang dimodifikasi oleh Propagation.NESTED Dibatalkan milik sub-transaksi transaksi eksternal. Transaksi utama perifer bergulir ke belakang, dan sub-transaksi harus bergulir kembali. Sub-transaksi internal dapat digulung kembali secara terpisah tanpa mempengaruhi transaksi utama perifer dan sub-transaksi lainnya.

4. Kesamaan dan kesamaan yang dibutuhkan, membutuhkan_new, bersarang

Dari perbandingan "1.2 Scene 2" dan "3.2 Scene 2", kita dapat melihat:

Metode internal yang dimodifikasi oleh bersarang dan diperlukan keduanya transaksi metode perifer. Jika metode periferal melempar pengecualian, transaksi kedua metode akan digulung kembali. Namun, yang diperlukan bergabung dengan transaksi metode perifer, sehingga termasuk transaksi yang sama dengan transaksi periferal. Setelah transaksi yang diperlukan melempar pengecualian dan digulung kembali, transaksi metode periferal juga akan digulung kembali. Nested adalah sub-transaksi dari metode periferal dan memiliki titik penyimpanan yang terpisah, sehingga metode bersarang melempar pengecualian dan digulung kembali, yang tidak akan mempengaruhi transaksi metode periferal.

Dari perbandingan "2.2 Scene 2" dan "3.2 Scene 2", kita dapat melihat:

Baik bersarang dan membutuhkan_new dapat mengembalikan transaksi metode internal tanpa mempengaruhi transaksi metode periferal. Namun, karena bersarang adalah transaksi bersarang, setelah metode periferal digulung kembali, sub-transaksi yang merupakan transaksi metode perifer juga akan digulung kembali. Persyaratan_new diimplementasikan dengan membuka transaksi baru. Transaksi internal dan transaksi perifer adalah dua transaksi. Rollback transaksi periferal tidak akan mempengaruhi transaksi internal.

5. Perilaku Propagasi Transaksi Lainnya

Mengingat masalah panjang artikel, tes perilaku propagasi transaksi lainnya tidak akan dijelaskan di sini. Pembaca yang tertarik dapat mencari kode uji yang sesuai dan penjelasan hasil dalam kode sumber. Portal: https: //github.com/tmtse/tran ...

Kasus Penggunaan Simulasi

Setelah memperkenalkan begitu banyak perilaku komunikasi transaksi, bagaimana kita menerapkannya dalam pekerjaan kita yang sebenarnya? Izinkan saya memberi Anda contoh:

Misalkan kita memiliki metode terdaftar, di mana metode penambahan poin dipanggil. Jika kami ingin menambahkan poin untuk tidak mempengaruhi proses pendaftaran (yaitu, rollback gagal untuk menambahkan poin tidak dapat membuat metode pendaftaran juga), kami akan menulis ini:

 @Service Public Class UserserServiceImpl mengimplementasikan UsersEverService {@transactional public void register (pengguna pengguna) {coba {MUGLESSHIPPOINTSERVICE.ADDPOINT (titik titik); } catch (exception e) {// empulur ...} // empulur ...} // empuk ...}

Kami juga menetapkan bahwa kegagalan pendaftaran akan mempengaruhi metode addPoint() (metode pendaftaran rollback juga memerlukan rollback), sehingga metode addPoint() perlu diimplementasikan seperti ini:

 @Service Public Class PublicHippointServiceImpl mengimplementasikan anggota HIPPOINTSERVICE {@transactional (propagation = propagation.nested) public void addPoint (titik titik) {coba {recordservice.addrecord (catatan catatan); } catch (exception e) {// empulur ...} // empulur ...} // empuk ...}

Kami memperhatikan bahwa metode addRecord() addPoint() , yang digunakan untuk merekam log. Implementasinya adalah sebagai berikut:

 @Service Public Class RecordServiceImpl mengimplementasikan RecordService {@transactional (propagation = propagation.not_supported) public void addRecord (catatan rekaman) {// olet ...} // olmit ...}

Kami memperhatikan propagation = Propagation.NOT_SUPPORTED dalam metode addRecord() , karena tidak akurat untuk log, dan satu dapat lebih atau kurang, sehingga metode addRecord() addRecord() sendiri dan metode addRecord() perifer addPoint() addPoint() tidak akan menyebabkan pengangkutan.

Melalui contoh ini, saya percaya bahwa setiap orang memiliki pemahaman yang lebih intuitif tentang penggunaan perilaku komunikasi transaksi. Kombinasi berbagai atribut memang dapat membuat implementasi bisnis kami lebih fleksibel dan beragam.

sebagai kesimpulan

Melalui pengantar di atas, saya percaya bahwa setiap orang memiliki pemahaman yang lebih dalam tentang perilaku komunikasi transaksi musim semi, dan saya berharap pekerjaan pengembangan harian Anda akan sangat membantu.

Meringkaskan

Di atas adalah seluruh konten artikel ini. Saya berharap konten artikel ini memiliki nilai referensi tertentu untuk studi atau pekerjaan semua orang. Jika Anda memiliki pertanyaan, Anda dapat meninggalkan pesan untuk berkomunikasi. Terima kasih atas dukungan Anda ke wulin.com.