Pemrosesan Pemulihan

Setelah segala jenis kegagalan yang mengganggu pemrosesan transaksi normal, KTM dan setiap manajer sumber daya harus melakukan operasi pemulihan. Pemulihan adalah proses di mana peserta transaksi tiba pada tampilan yang konsisten dari setiap status transaksi.

Manajer sumber daya mungkin ragu tentang hasil transaksi, yang berarti bahwa pada saat kegagalan, mereka telah menerima pemberitahuan TRANSACTION_NOTIFY_PREPARE, telah bersiap untuk penyimpanan yang tahan lama, tetapi belum menerima (atau menerima tetapi tidak mencatat) hasil akhir untuk transaksi tersebut. Demikian pula, KTM dapat ragu terhadap transaksi jika telah disiapkan tetapi belum menerima (atau menerima tetapi tidak mencatat) hasil. Pada waktu pemulihan, semua hasil yang telah dikirim tetapi tidak diakui harus dikirim ulang. Misalnya, jika manajer sumber daya menerima pemberitahuan TRANSACTION_NOTIFY_COMMIT dan memanggil fungsi CommitComplete, RM mungkin masih menerima pemberitahuan TRANSACTION_NOTIFY_COMMIT duplikat pada waktu pemulihan.

Agar transaksi pulih dengan benar setelah manajer sumber daya atau kegagalan sistem, setiap manajer sumber daya harus melakukan hal berikut setiap kali dimulai:

1. Panggil fungsi OpenResourceManager untuk membuka kembali pegangannya sebagai manajer sumber daya menggunakan nama unik dan persisten. Ini memberi tahu KTM bahwa manajer sumber daya berjalan lagi dan tersedia untuk melakukan pemulihan. Jika tidak ada pendaftaran yang harus dipulihkan, panggilan ke OpenResourceManager dapat gagal. Panggil createResourceManager untuk membuat ulang objek RM.

2. Panggil RecoverResourceManager. Manajer sumber daya akan menerima event pemberitahuan TRANSACTION_NOTIFY_RECOVER untuk setiap pendaftar yang perlu melakukan operasi pemulihan, diikuti oleh TRANSACTION_NOTIFY_LAST_RECOVER. Peristiwa pemberitahuan mencakup pengidentifikasi unik global untuk transaksi dan pendaftaran.

3. Panggil fungsi OpenEnlistment untuk membuka kembali setiap handle pendaftaran yang menerima pemberitahuan TRANSACTION_NOTIFY_RECOVER dari manajer sumber daya.

4. Untuk setiap pendaftaran yang dibuka oleh OpenEnlistment, panggil RecoverEnlistment. Hal ini menyebabkan pemberitahuan TRANSACTION_NOTIFY_COMMIT atau TRANSACTION_NOTIFY_INDOUBT disebarkan ulang.

5. Jika RM menerima TRANSACTION_NOTIFY_COMMIT, RM dapat menyelesaikan transaksi dengan memanggil CommitComplete.

   Jika RM menerima TRANSACTION_NOTIFY_INDOUBT, RM harus menunggu pemberitahuan hasil tiba.

6. Untuk setiap transaksi di mana RM tidak menerima pemberitahuan TRANSACTION_NOTIFY_RECOVER, tetapi sebelumnya menerima pemberitahuan TRANSACTION_NOTIFY_PREPARE, RM harus memproses transaksi seolah-olah dibatalkan.

Nota

Resource manager diizinkan untuk mendaftar atau membuat transaksi baru saat dalam proses melakukan pemulihan.

 

KTM menggunakan yang diduga membatalkan model transaksi. Skenario berikut mengilustrasikan perilaku ini. Asumsikan bahwa KTM dan manajer sumber daya ada di komputer yang sama. Misalkan KTM mengeluarkan pemberitahuan persiapan untuk transaksi, tetapi sistem mengalami crash sebelum KTM mencatat pemberitahuan persiapan. Misalkan lebih lanjut bahwa manajer sumber daya menerima dan mencatat pemberitahuan persiapan tepat sebelum sistem crash. Setelah sistem dipulihkan, KTM tidak memiliki pengetahuan tentang transaksi, karena tidak pernah mencatat fase persiapan. Manajer sumber daya memiliki pengetahuan tentang transaksi, karena menerima, memproses, dan mencatat pemberitahuan persiapan. Ketika KTM mengeluarkan pemberitahuan pemulihannya, resource manager tidak menyertakan pemberitahuan pemulihan untuk transaksi yang dimaksud. Dengan model pembatalan yang diduga, manajer sumber daya dalam hal ini akan memperlakukan transaksi yang disiapkan sebagai dibatalkan ketika tidak menerima pemberitahuan untuk melakukan pemulihan pada transaksi tersebut.