コンピューティングの黎明期には、分散トランザクションは必要ありませんでした。 アプリケーションの数が増えるにつれて、データの同期が重要な問題になります。 企業は、データ フローの観点から同期システムを維持するために多額の費用を支払いました。 その結果、XA(eXtended Architecture) と呼ばれる 2 フェーズ コミット プロトコルが生まれました。 このプロトコルは、グローバル トランザクション処理に ACID に似たプロパティを提供します。 この記事では、XA トランザクションの詳細と、Spring フレームワークでの XA トランザクションの使用について説明します。

2 フェーズ コミット プロトコルは、分散システム用のアトミック コミットメント プロトコルです。 このプロトコルは、その名前が示すとおり、2 つのフェーズで構成されています。 1 つ目は、トランザクション マネージャーがすべてのトランザクション リソースを調整してコミットまたは中止するコミット要求フェーズです。 コミット フェーズでは、トランザクション マネージャーは、各トランザクション リソースの投票に応じてコミットまたは中止することにより、操作を終了することを決定します。 次に、2PC プロトコルの実装の詳細に進みます。

2PC による Java + .NET 相互運用性に関するリソースについては、こちらを参照してください。

XA トランザクションには、XA リソースごとにグローバル トランザクション ID とローカル トランザクション ID (xid) が必要です。 各 XA リソースは、start(xid) メソッドによって XA マネージャーに登録されます。 このメソッドは、XA リソースがトランザクションに関与していることを示します (操作の準備ができている)。 その後、2PC プロトコルの最初のフェーズは、prepare(xid) メソッドを呼び出すことによって実現されます。 このメソッドは、XA リソースからの OK または ABORT 投票を要求します。 各 XA リソースからの投票を受け取った後、XA マネージャーは、すべての XA リソースが OK を送信した場合にコミット (xid) 操作を実行することを決定し、XA リソースが ABORT を送信した場合にロールバック (xid) を実行することを決定します。 最後に、XA リソースごとに end(xid) メソッドが呼び出され、トランザクションが完了したことが通知されます。 図を見て理解を深めてください。 XA トランザクションの実装の背景を構築するにつれて、次はさらに深く掘り下げて、このコマンドを入力してください。


ネットワークの損失、マシンのダウン、および管理者のミスにより、いつでも障害が発生する可能性があります。 XA トランザクションでは、発生するフェーズに従ってこれらの障害を分類します。 最初の障害フェーズは、プロトコルが開始される前です。 これは、システムがロールバックやその他の操作を行う必要がない単純な障害です。 その特定の瞬間のための操作は行いません。 次に、このコマンドを入力します このコマンド このコマンドの失敗は、タイムアウト ポリシーを使用したロールバックによって簡単に処理できる準備 (コミット要求) フェーズで発生する可能性があります。 最後になりましたが、不完全なロールバックやチェーンの問題が原因で発生する可能性のあるコミット フェーズの失敗です。 上記のすべての状況で、トランザクション マネージャーは問題の回復を試みます。 次に、トランザクション マネージャーがどのように障害を克服しようとするかを見ていきます。

回復時に、トランザクション マネージャーは各 XA リソースの回復メソッドを呼び出します。 XA リソースはログをトレースし、最新の状態を再構築しようとします。 Transaction Manager が必要なロールバック操作を呼び出し、ミッションが達成されます。 このプロセスは一見楽に思えるかもしれませんが、ログが破損するなど、ログに問題が発生する例外的な状況が数多くあります。 このような状況では、トランザクション マネージャーはいくつかのヒューリスティックに従って問題を解決します。 また、復旧処理は、適用前に操作ログを書き込む先行書き込みログに依存します。 パフォーマンスの問題では、これらのログは独自の形式 (シリアル化を使用しない) で書き込まれ、システムは可能であればそれらをバッチ処理する必要があります。 次に、Spring フレームワークによる XA トランザクションのサポートという楽しい部分に進みます。

Spring フレームワークは、Web およびスタンドアロン アプリケーションを開発するための広範な環境を提供します。 Spring が提供する他のユーティリティと同様に、XA トランザクションも Spring でサポートされています。 ただし、このサポートはネイティブ実装ではなく、休止状態、Web コンテナー、または XA トランザクション管理を提供するフレームワークが必要です。 Spring には、トランザクション管理ユーティリティを提供し、詳細を隠す JtaTransactionManager があります。 このようにして、同時に更新される複数の DataSource のトランザクション管理を行うことができます。 XA トランザクション管理の使用に関しては、XA トランザクションの休止状態と Web コンテナーのサポートが十分に文書化されているため、言及する必要はありません。 ただし、XA トランザクションを提供するフレームワークを使用すると、混乱する可能性があります。 したがって、Bitronix Transaction Manager を紹介して、この投稿を続けます。

Bitronix は、トランザクション管理の優れたサポートを提供しながら、簡単に構成できます。 スタンドアロン アプリケーションでは一般的に使用されませんが、次のようにスタンドアロン アプリケーション用の構成を与えようとします。

次のように構成できる複数のデータ ソースを使用できるようになりました。 各データ ソースには、一意の uniqueName プロパティが必要です。 以下の構成は Oracle 用であり、他のデータベースは異なる構成を持つことができます。 その他の詳細については、Bitronix Web サイトを確認できます。

要約すると、XA トランザクション、基礎となるプロトコル、およびスタンドアロン アプリケーションでの Spring との Bitronix トランザクション管理の統合とは何かを説明しようとしました。 拡張するために、XA トランザクションでは、さまざまなデータ ソースを同時に変更できます。 さらに、XA トランザクションは、Web コンテナーまたは休止状態のようなフレームワークによってサポートされます。 それにもかかわらず、トランザクション管理を、トランザクション マネージャーを構成する必要があるスタンドアロン アプリケーションに統合する必要がある場合があります。 その結果、XA トランザクションは複数のデータ ソースに対して一貫した操作を提供し、企業はそれらを利用します。
この記事が「XA トランザクションの実行方法 (2 フェーズ コミット): 簡単なガイド」の参考になれば幸いです。 他にご不明な点がございましたら、お気軽にお問い合わせください。 以下のセクションでお問い合わせください。 共有することを忘れないでください signalfix.net ご家族やお友達と!