Kesalahan Server-Side

Pendengar dan pemutar bekerja sama untuk menangani pesan racun. Jika transaksi yang diputar kembali gagal, Antrean Pesan memindahkan pesan input kembali ke antrean input. Pemutar membatalkan transaksi jika menerima HRESULT yang gagal dari komponen server atau jika menangkap pengecualian. Jika masalah berlanjut, pendengar dapat mengulang terus-menerus dalam pola berikut:

• Menghapus antrean pesan
• Membuat instans objek
• Menderita pembatalan
• Menempatkan pesan kembali di bagian atas antrean

Layanan komponen yang diantrekan menangani kegagalan ini dengan menggunakan serangkaian antrean coba lagi khusus aplikasi. Dibuat saat komponen diinstal, ada tujuh antrean untuk setiap aplikasi, sebagai berikut:

1. Antrean input normal. Nama antrean ini adalah nama aplikasi COM+. Ini adalah antrean publik Antrean Pesan.

2. Antrean coba lagi pertama. Pesan dipindahkan ke sini jika transaksi berulang kali gagal saat memproses pesan dari antrean input normal. Pesan pada antrean ini diproses setelah satu menit. Pesan dapat dicoba ulang tiga kali pada antrean ini sebelum dipindahkan ke bagian belakang antrean coba lagi kedua. Antrean ini diberi nama ApplicationName_0. Antrean ini adalah antrean Antrean Pesan privat.

3. Antrean coba lagi kedua. Pesan dipindahkan ke sini jika transaksi berulang kali gagal saat memproses pesan dari antrean coba lagi pertama. Pesan pada antrean ini diproses setelah dua menit. Pesan dapat dicoba ulang tiga kali pada antrean ini sebelum dipindahkan ke bagian belakang antrean coba lagi ketiga. Antrean ini diberi nama ApplicationName_1. Antrean ini adalah antrean Antrean Pesan privat.

4. Antrean coba lagi ketiga. Pesan dipindahkan ke sini jika transaksi berulang kali gagal saat memproses pesan dari antrean coba lagi kedua. Pesan pada antrean ini diproses setelah empat menit. Pesan dapat dicoba ulang tiga kali pada antrean ini sebelum dipindahkan ke bagian belakang antrean coba lagi keempat. Antrean ini diberi nama ApplicationName_2. Antrean ini adalah antrean Antrean Pesan privat.

5. Antrean coba lagi keempat. Pesan dipindahkan ke sini jika transaksi berulang kali gagal saat memproses pesan dari antrean coba lagi ketiga. Pesan pada antrean ini diproses setelah delapan menit. Pesan dapat dicoba ulang tiga kali pada antrean ini sebelum dipindahkan ke antrean coba lagi kelima. Antrean ini diberi nama ApplicationName_3. Antrean ini adalah antrean Antrean Pesan privat.

6. Antrean coba lagi kelima. Pesan dipindahkan ke sini jika transaksi berulang kali gagal saat memproses pesan dari antrean coba lagi keempat. Pesan pada antrean ini diproses setelah enam belas menit. Pesan dapat dicoba ulang tiga kali pada antrean ini sebelum dipindahkan ke antrean istirahat akhir. Antrean ini diberi nama ApplicationName_4. Ini adalah antrean Antrean Pesan privat.

7. Antrean istirahat akhir khusus aplikasi. Pesan dipindahkan ke sini jika transaksi berulang kali dibatalkan saat dicoba pada antrean coba lagi kelima. Antrean ini diberi nama _DeadQueue ApplicationName. Ini adalah antrean Antrean Pesan privat. Antrean istirahat terakhir tidak dilayankan oleh pendengar antrean. Pesan tetap di sini sampai dipindahkan secara manual (mungkin oleh utilitas pemindah pesan komponen yang diantrekan) atau dihapus menyeluruh oleh Penjelajah Antrean Pesan.

Pesan yang tidak dapat diputar karena jelas bahwa setiap upaya coba lagi akan gagal dapat dipindahkan langsung ke antrean istirahat akhir khusus aplikasi tanpa dimajukan melalui semua tingkat coba lagi.

Pemain mengeluarkan peristiwa COM+ untuk memberi tahu pihak yang tertarik bahwa pesan tidak dapat diputar. Peristiwa COM+ dikeluarkan dalam situasi berikut:

• Ketika transaksi dibatalkan
• Saat pesan dipindahkan dari satu antrean ke antrean lainnya
• Saat pesan didepositkan ke antrean istirahat akhir

Pesan dapat dimodifikasi sebelum berpindah dari satu antrean ke antrean lainnya. Mekanisme keamanan komponen yang diantrekan COM+ memungkinkan pesan dipindahkan untuk mencoba kembali antrean dan kemudian dimasukkan kembali ke dalam antrean input awal aplikasi. Untuk informasi selengkapnya tentang keamanan komponen yang diantrekan, lihat Keamanan Komponen Antrean.

Antrean coba lagi dibuat bersama dengan antrean aplikasi utama ketika aplikasi ditandai sebagai antrean oleh alat administrasi Layanan Komponen atau dengan menggunakan fungsi SDK Administratif COM+. Layanan komponen yang diantrekan memungkinkan fleksibilitas dalam mekanisme coba lagi dengan memungkinkan antrean coba lagi dihapus. Misalnya, jika semua antrean coba lagi dihapus, pesan yang terus-menerus dibatalkan akan dipindahkan langsung dari antrean aplikasi ke antrean istirahat akhir khusus aplikasi. Dengan menghapus satu atau beberapa antrean coba lagi, jumlah dan panjang percobaan ulang dapat dikurangi. Jika antrean dihapus dari urutan coba lagi, waktu antrean yang tersisa sesuai dengan posisi dalam urutan antrean coba lagi. Misalnya, jika Anda menghapus antrean coba lagi ApplicationName_1, ApplicationName_2, dan ApplicationName_3, pesan pada ApplicationName_4 akan diproses seolah-olah antrean adalah antrean coba lagi kedua.

Mekanisme coba lagi dirancang untuk menyelesaikan pesan jika memungkinkan. Dalam beberapa kasus, mungkin tidak mungkin pesan berhasil. Misalnya, klien mungkin mencoba menarik uang dari akun yang memiliki dana yang tidak mencukup. Dalam keadaan ini, Anda dapat menangani kesalahan dengan sejumlah cara, termasuk yang berikut ini:

• Membuat diagnostik dan mengeluarkan peringatan
• Membuat transaksi kompensasi
• Abaikan masalah dan tutup pesan

Seperti kegagalan persisten sisi klien, layanan komponen yang diantrekan memungkinkan kelas pengecualian dikaitkan dengan komponen. Kelas pengecualian dikaitkan dengan komponen dengan menggunakan tab Tingkat Lanjut di halaman properti komponen alat administrasi Layanan Komponen atau dengan menggunakan fungsi Administratif COM+. Kelas pengecualian memungkinkan pengembang untuk memiliki kontrol setelah pesan dicoba kembali dan sebelum pesan tersebut dipindahkan ke antrean istirahat akhir khusus aplikasi. Untuk informasi selengkapnya tentang kelas pengecualian, lihat Kegagalan Client-Side Persisten.

Berikut ini adalah urutan peristiwa untuk penanganan pengecualian sisi server:

1. Pesan dipindahkan melalui antrean coba lagi khusus aplikasi yang tersedia.
2. Coba lagi terakhir pada antrean coba lagi terakhir gagal.
3. Run-time layanan komponen yang diantrekan mengambil komponen target dari pesan dan memeriksa kelas pengecualian.
4. Run-time membuat instans kelas pengecualian.
5. Kueri run-time IPlaybackControl pada kelas pengecualian.
6. Run-time memanggil IPlaybackControl::FinalServerRetry di kelas pengecualian.
7. Run-time memutar kembali semua panggilan properti dan metode dari pesan ke kelas pengecualian.
8. Jika langkah 4 hingga 6 tidak berhasil, run-time memindahkan pesan ke antrean istirahat akhir khusus aplikasi.

Jika Anda perlu mengintervensi proses yang dijelaskan di atas atau Anda perlu memindahkan pesan racun dari antrean istirahat terakhirnya, gunakan utilitas pemindah pesan. Untuk informasi selengkapnya tentang utilitas pemindah pesan, lihat Menangani Kesalahan.

Topik terkait

KesalahanClient-Side

Kegagalan Client-Side Persisten