23.2. WS-BA リカバリ

WS-BA コーディネーションサービスの実装は、アクティビティが完了／終了するまでの各パーティシパントの状態をトラッキングします。CoordinatorCompletion のパーティシパントすべてがcomplete メッセージを受信しcompleted メッセージで返答すると、移行ポイントがアクティビティの終了中に発生します。この時点で、ParticipantCompletionパーティシパントはすべてcompleted メッセージを送信しているはずです。コーディネータは各パーティシパントの詳細を格納しトランザクション終了の準備ができていることを示すログを書き込みます。コーディネータサービスがログ記録の書き込み後にクラッシュした場合、close 操作は問題なく行えるよう保証されています。コーディネータはシステムが再起動しclose メッセージを全パーティシパントに送信後ログをチェックします。全パーティシパントがclosed メッセージでclose に返答した後、コーディネータはログエントリを無事に削除することができます。

複数回クラッシュする場合、コーディネータはクラッシュ前に送信されたclose メッセージに対応する必要も、メッセージを再送信する必要もありません。XTS パーティシパントの実装はclose メッセージの再送にも対応しています。以下に説明されているようにパーティシパントがリカバリ機能を実装しているとの前提で、これとパーティシパントのサービスホスト１つ以上が同時にクラッシュした場合でもコーディネータはclose メッセージを確実に送信することができます。

コーディネータサービスがログ記録に書き込む前にクラッシュした場合、明示的に完了したパーティシパントを補正する必要はありません。推定アボートプロトコルが確実に、完了済みパーティシパントすべてにcompensate メッセージが送信されるようにします。

アクティビティがキャンセルされた場合はログ記録を書き込む必要がありません。パーティシパントがcancelやcompensate リクエストに返答しない場合、コーディネータは警告ログを残しそのまま継続します。推定アボートプロトコルとパーティシパント主導のリカバリを組み合わせることで、パーティシパントホストがクラッシュした場合でも、適宜全パーティシパントが最終的にキャンセルあるいは補正されるようにします。

完了済みのパーティシパントがcompleted レスポンスを数回再送した後にコーディネータからのレスポンスを検出しない場合、getstatus メッセージの送信に切り替えコーディネータがまだ状態を把握しているかを判断します。ログ記録を書き込む前にクラッシュが発生した場合、コーディネータが再起動すると、コーディネータにはパーティシパントの記録がなく、getstatus リクエストは問題があると返されます。パーティシパントのリカバリマネージャはこの状態で、このアクティビティがクライアントによりキャンセルされたかのようにパーティシパントを自動補正します。

パーティシパントのクラッシュ後、パーティシパントのリカバリマネージャは完了済みのパーティシパント毎にログエントリを検出します。getstatus メッセージを各パーティシパントのコーディネータホストに送信し、アクティビティがまだ存在するか判断します。コーディネータがクラッシュしておらず、アクティビティが動作している場合、パーティシパントはcompletedメッセージの再送に切り替え、close あるいは compensateのレスポンスを待ちます。コーディネータもクラッシュしているか、アクティビティがキャンセルされている場合、パーティシパントは自動でキャンセルされます。