回復処理

通常のトランザクション処理を中断する障害の種類が発生した後、KTM と各リソース マネージャーは 回復 操作を実行する必要があります。 復旧は、トランザクション参加者が各トランザクションの状態の一貫したビューに到達するプロセスです。

リソース マネージャーは、トランザクションの結果について 疑い を持っている可能性があります。つまり、失敗時に、TRANSACTION_NOTIFY_PREPARE通知を受け取り、永続ストレージを準備していたが、トランザクションの最終結果を受信 (または受信したがログに記録されなかった) ことを意味します。 同様に、KTM が準備されているが、結果を受け取っていない (または受信したがログに記録されていない) 場合、KTM はトランザクションについて疑わしい可能性があります。 復旧時に、送信されたが確認されなかったすべての結果を再送信する必要があります。 たとえば、リソース マネージャーがTRANSACTION_NOTIFY_COMMIT通知を受信し、 CommitComplete 関数を呼び出した場合でも、RM は復旧時に重複するTRANSACTION_NOTIFY_COMMIT通知を受け取る可能性があります。

リソース マネージャーまたはシステム障害の後にトランザクションを適切に復旧するには、各リソース マネージャーが開始されるたびに次の操作を行う必要があります。

1. OpenResourceManager 関数を呼び出して、一意の永続的な名前を使用してリソース マネージャー ハンドルを再度開きます。 これにより、リソース マネージャーが再び実行され、回復を実行できるようになることが KTM に通知されます。 回復する参加リストが存在しない場合、 OpenResourceManager の呼び出しは失敗する可能性があります。 CreateResourceManager を呼び出して、RM オブジェクトを再作成します。

2. RecoverResourceManager を呼び出します。 リソース マネージャーは、回復操作を実行する必要がある各参加リストの TRANSACTION_NOTIFY_RECOVER 通知イベントを受け取り、その後にTRANSACTION_NOTIFY_LAST_RECOVERを受け取ります。 通知イベントには、トランザクションと参加リストの両方のグローバル一意識別子が含まれます。

3. OpenEnlistment 関数を呼び出して、リソース マネージャーがTRANSACTION_NOTIFY_RECOVER通知を受信した各参加ハンドルを再度開きます。

4. OpenEnlistment によって開かれた各参加リストについて、RecoverEnlistment を呼び出します。 これにより、TRANSACTION_NOTIFY_COMMITまたはTRANSACTION_NOTIFY_INDOUBT通知が再配信されます。

5. RM がTRANSACTION_NOTIFY_COMMIT受信した場合、RM は CommitComplete を呼び出してトランザクションを完了できます。

   RM がTRANSACTION_NOTIFY_INDOUBT受信した場合、RM は結果通知が到着するまで待機する必要があります。

6. RM がTRANSACTION_NOTIFY_RECOVER通知を受け取らず、以前にTRANSACTION_NOTIFY_PREPARE通知を受け取ったトランザクションの場合、RM はトランザクションをロールバックされたかのように処理する必要があります。

KTM では、 推定中止 トランザクション モデルが使用されます。 次のシナリオは、この動作を示しています。 KTM とリソース マネージャーが同じコンピューター上に存在するとします。 KTM がトランザクションの準備通知を発行したが、KTM が準備通知をログに記録する前にシステムがクラッシュするとします。 さらに、システムがクラッシュする直前に、リソース マネージャーが準備通知を受信してログに記録するとします。 システムが復元された後、KTM は準備フェーズをログに記録しなかったため、トランザクションに関する知識がありません。 リソース マネージャーは、準備通知を受信、処理、ログに記録したため、トランザクションに関する知識を持っています。 KTM が回復通知を発行すると、リソース マネージャーには、問題のトランザクションの回復通知は含まれません。 推定中止モデルでは、この場合、リソース マネージャーは、準備されたトランザクションを、そのトランザクションに対して復旧を実行するための通知を受け取らない場合に中止として扱います。