Pemrosesan Pemulihan

Setelah setiap 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 pandangan yang konsisten dari setiap status transaksi.

Resource manager mungkin ragu dengan 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 tentang 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 handel manajer sumber dayanya menggunakan nama persisten yang unik. Ini menginformasikan KTM bahwa manajer sumber daya berjalan lagi dan tersedia untuk melakukan pemulihan. Jika tidak ada pendaftaran yang dapat dipulihkan, panggilan ke OpenResourceManager dapat gagal. Panggil CreateResourceManager untuk membuat ulang objek RM.

2. Panggil RecoverResourceManager. Manajer sumber daya akan menerima peristiwa pemberitahuan TRANSACTION_NOTIFY_RECOVER untuk setiap pendaftaran yang perlu dilakukan 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 handel pendaftaran tempat manajer sumber daya menerima pemberitahuan TRANSACTION_NOTIFY_RECOVER.

4. Untuk setiap pendaftaran yang dibuka oleh OpenEnlistment, panggil RecoverEnlistment. Ini menyebabkan pemberitahuan TRANSACTION_NOTIFY_COMMIT atau TRANSACTION_NOTIFY_INDOUBT dikirim 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 yang tidak diterima RM TRANSACTION_NOTIFY_RECOVER pemberitahuan, tetapi sebelumnya menerima pemberitahuan TRANSACTION_NOTIFY_PREPARE, RM harus memproses transaksi seolah-olah digulung balik.

KTM menggunakan model transaksi pembatalan yang diduga . 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. Lebih lanjut misalkan 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.