2フェーズ・コミットとインダウト・トランザクション

2フェーズ・コミット

2フェーズ・コミットは準備フェーズ、コミットフェーズの2つのフェーズでトランザクションを処理することでトランザクションの原子性を保障するメカニズムです。

■ 2フェーズ・コミットを採用しない場合
2フェーズ・コミットを採用しない場合、下図のように原子性が保障できません。

■ 2フェーズ・コミットでは
2フェーズ・コミットでは、準備フェーズでDBはコミット準備を行いトランザクション・マネージャへコミット可能票を投票し、コミットフェーズで全てのDBがコミット可能票を投票した場合コミットします。
拒否票が1票でも投票された場合はロールバックします。

2フェーズ・コミットでは、このように２つのフェーズでトランザクションの原子性を保障します。

※図中の不確定区間(インダウト)はコミット/ロールバックのどちらを行うかが確定していない区間を指します。

インダウト・トランザクション

2フェーズ・コミットのコミットフェーズで障害が発生した場合、DBのトランザクションがコミット/ロールバックが確定しないインダウト状態となります。
このインダウト状態が発生したトランザクションをインダウト・トランザクションと言います。
インダウト・トランザクションはリカバリするまでアクセスしていたデータをロックし続けます。そのため早期な検出、リカバリが必要になります。

下図ではDB２でインダウト状態が発生しています。

MSDTC×Oracleの環境ではOracle MTS Recovery Service、リカバリ・ジョブ(DBMS_JOBパッケージで登録するジョブ)で自動リカバリを実現します。
MSDTC×Oracleの自動リカバリについてはいずれ詳細をPOSTします。

RACでの分散トランザクション

RACで分散トランザクションを行う場合は、同じ分散トランザクションの異なるブランチはかならず１つのインスタンスに置くように処理を転送する必要がある。

同じ分散トランザクションの異なるブランチがRACデータベースの異なるインスタンスに置かれる状態をスプリット・ブランチといい、スプリット・ブランチが発生すると分散トランザクションは正しく処理されない。

スプリット・ブランチを避けるためには、優先インスタンスを1つだけ持つシングルトン・サービスを作成する。






参考：RACでXAを使用するためのベスト・プラクティス
http://otndnld.oracle.co.jp/products/database/clustering/pdf/bestpracticesforxaandrac.pdf

MSDTCの罠

MSDTCはコミットフェーズのシーケンスにちょっとした罠があり、見事にはまったのでメモ。

準備フェーズで全てのリソースマネージャから準備完了のメッセージを受信したら、コミットフェーズでアプリへのコミット通知とリソースマネージャーへのコミットメッセージの送信を非同期に行う。

そのためアプリにコミット通知を行ったはいいが、図中の③、④のポイントで障害が発生すると不確定区間のためインダウト トランザクションとして残ってしまう。

アプリとしてはMSDTCからコミットを受けているので正常フローするが、実際はトランザクションがコミットされず、インダウト トランザクションとしてリソースをロックし続けている状態になってしまう。