Seperti semua hal yang berhubungan dengan kinerja, jawabannya adalah:itu tergantung. Secara khusus, itu tergantung pada bagaimana Anda menggunakan driver.
Biaya interaksi transaksional dengan database dibagi secara kasar menjadi:overhead kompleksitas kode, overhead komunikasi, pemrosesan sql, dan I/O disk.
Overhead komunikasi agak berbeda antara kasus XA dan non-XA. Semuanya sama, transaksi XA membawa biaya lebih sedikit di sini karena memerlukan lebih banyak perjalanan pulang pergi ke db. Untuk transaksi non-XA dalam mode komit manual, biayanya setidaknya dua panggilan:operasi sql dan komit. Dalam kasus XA itu mulai, operasi sql, akhiri, persiapkan dan komit. Untuk kasus penggunaan khusus Anda yang secara otomatis akan dioptimalkan untuk memulai, operasi sql, akhiri, persiapan. Tidak semua panggilan memiliki biaya yang sama:data yang dipindahkan dalam kumpulan hasil biasanya akan mendominasi. Pada LAN biaya perjalanan pulang pergi tambahan biasanya tidak signifikan.
Namun perhatikan bahwa ada beberapa gotcha menarik yang menunggu yang tidak waspada. Misalnya, beberapa driver tidak mendukung cache pernyataan yang disiapkan dalam mode XA, yang berarti bahwa penggunaan XA membawa overhead tambahan untuk menguraikan ulang SQL pada setiap panggilan, atau mengharuskan Anda untuk menggunakan kumpulan pernyataan terpisah di atas driver. Sementara pada topik kumpulan, penyatuan koneksi XA dengan benar sedikit lebih kompleks daripada penyatuan yang non-XA, jadi tergantung pada implementasi kumpulan koneksi, Anda mungkin melihat sedikit pukulan di sana juga. Beberapa kerangka kerja ORM sangat rentan terhadap overhead pooling koneksi jika mereka menggunakan pelepasan koneksi yang agresif dan memperoleh kembali dalam lingkup transaksi. Jika memungkinkan, konfigurasikan untuk mengambil dan menahan koneksi selama masa pakai tx alih-alih memukul kumpulan beberapa kali.
Dengan peringatan yang disebutkan sebelumnya mengenai caching pernyataan yang disiapkan, tidak ada perbedaan material dalam biaya penanganan sql antara XA dan non-XA tx. Namun ada sedikit perbedaan pada penggunaan sumber daya pada server db:dalam beberapa kasus, server dapat melepaskan sumber daya lebih cepat dalam kasus non-XA. Namun, transaksi biasanya cukup singkat sehingga ini bukan pertimbangan yang signifikan.
Sekarang kita mempertimbangkan overhead I/O disk. Di sini kita memperhatikan I/O yang disebabkan oleh protokol XA daripada SQL yang digunakan untuk logika bisnis, karena yang terakhir tidak berubah dalam kedua kasus tersebut. Untuk transaksi hanya baca situasinya sederhana:manajer db dan tx yang masuk akal tidak akan melakukan penulisan log apa pun, jadi tidak ada biaya tambahan. Untuk kasus penulisan, hal yang sama berlaku di mana db adalah satu-satunya sumber daya yang terlibat, karena optimasi komit satu fase XA. Untuk kasus 2PC, setiap server db atau manajer sumber daya lainnya memerlukan dua penulisan disk alih-alih yang digunakan dalam kasus non-XA, dan manajer tx juga membutuhkan dua. Berkat kelambatan penyimpanan disk, ini adalah sumber dominan overhead kinerja di XA vs. non-XA.
Beberapa paragraf kembali saya sebutkan kompleksitas kode. XA membutuhkan eksekusi kode yang sedikit lebih banyak daripada non-XA. Dalam kebanyakan kasus, kerumitannya terkubur dalam manajer transaksi, meskipun Anda tentu saja dapat mengemudikan XA secara langsung jika Anda mau. Biaya sebagian besar sepele, tunduk pada peringatan yang telah disebutkan. Kecuali Anda menggunakan manajer transaksi yang sangat buruk, dalam hal ini Anda mungkin memiliki masalah. Kasus read-only sangat menarik - penyedia manajer transaksi biasanya menempatkan upaya pengoptimalan mereka ke dalam kode I/O disk, sedangkan lock contention adalah masalah yang lebih signifikan untuk kasus penggunaan read-only, terutama pada sistem yang sangat bersamaan.
Perhatikan juga bahwa kompleksitas kode di tx manager adalah sesuatu yang membingungkan dalam arsitektur yang menampilkan server aplikasi atau penyedia manajer transaksi standar lainnya, karena ini biasanya menggunakan kode yang hampir sama untuk koordinasi transaksi XA dan non-XA. Dalam kasus non-XA, untuk melewatkan tx manager sepenuhnya, Anda biasanya harus memberi tahu server/kerangka kerja aplikasi untuk memperlakukan koneksi sebagai non-transaksional dan kemudian mengarahkan komit secara langsung menggunakan JDBC.
Jadi ringkasan adalah:Biaya kueri sql Anda akan mendominasi waktu transaksi hanya baca terlepas dari pilihan XA/non-XA , kecuali jika Anda mengacaukan sesuatu dalam konfigurasi atau melakukan operasi sql yang sangat sepele di setiap tx, yang terakhir menjadi tanda logika bisnis Anda mungkin dapat menggunakan beberapa restrukturisasi untuk mengubah rasio overhead manajemen tx ke logika bisnis di setiap tx.
Untuk kasus hanya-baca, saran agnostik protokol transaksi biasa berlaku:pertimbangkan cache tingkat kedua tingkat kesadaran transaksi dalam solusi ORM daripada memukul DB setiap kali. Jika gagal, setel sql, lalu tingkatkan cache buffer db hingga Anda melihat 90%+ hit rate atau Anda memaksimalkan slot RAM server, mana saja yang lebih dulu. Hanya khawatir tentang XA vs. non-XA setelah Anda selesai melakukannya dan ternyata semuanya masih terlalu lambat.
