6.1 リソース・マネージャの計画

この項で説明する点を考慮して、リソース・マネージャについて計画します。選択するリソース・マネージャとその使用方法に応じて、アプリケーションの構成要件は異なります。

• サポートされているリソース・マネージャ
  トランザクション参加側サービスは、リソース・マネージャを使用してアプリケーション・データを格納できます。
• リソース・マネージャのサポートされているドライバ
  使用するリソース・マネージャで機能する、正しいJDBCドライバとUCPバージョンを必要に応じて選択するのはアプリケーション開発者の責任です。
• 非XAリソースの最適化
  ロギング・ラスト・リソース(LLR)またはラスト・リソース・コミット(LRC)の最適化を使用すると、1つの非XAリソースがグローバル・トランザクションに参加できるようになります。
• 複数のアプリケーションの共通リソース・マネージャ
  複数の参加側サービスに共通リソース・マネージャを使用する場合、MicroTxはコミット処理を最適化できるため、XAトランザクションのスループットが向上し、レイテンシが低下します。
• 1つのアプリケーションでの複数のリソース・マネージャの構成
  1つの参加側サービスに対して複数のリソース・マネージャを使用できます。ビジネス・ロジックに基づいて、1つの参加側サービスは、複数のXA準拠リソース・マネージャに接続できます。ただし、1つのトランザクションで非XAリソースは1つしかサポートされません。
• XAトランザクションの動的リカバリについて
  トランザクション・コーディネータ・サーバーは、障害後にサーバーが再起動したときに進行中のトランザクションを再開します。

6.1.1 サポートされているリソース・マネージャ

トランザクション参加側サービスは、リソース・マネージャを使用してアプリケーション・データを格納できます。

XAトランザクションでは、MicroTxライブラリがリソース・マネージャのクライアント・ライブラリにアクセスする必要があります。

Javaアプリケーションでサポートされているリソース・マネージャ

XAトランザクションに参加するJavaアプリケーションの場合、MicroTxライブラリは次のリソース・マネージャでテストされます:

• Oracle Database 19c
• Oracle Real Application Clusters (RAC) 19c
• PostgreSQL 14.2

Node.jsアプリケーションでサポートされているリソース・マネージャ

XAトランザクションに参加するNode.jsアプリケーションの場合、MicroTxライブラリはOracle Database 19.xおよびOracle RAC 19cでテストされます。

サポートされている非XAリソース

XAトランザクションに参加するアプリケーションは、単一の非XAリソースを使用できます。MicroTxライブラリは、次の非XAリソースでテストされます:

• MongoDB 4.1以上
• MySQL

詳細は、「非XAリソースの最適化」を参照してください。

TCCまたはLRAトランザクション・プロトコルを使用するアプリケーションでサポートされているデータベース

トランザクション・プロトコルとしてLRAまたはTCCを選択した場合は、任意のデータベースを使用してアプリケーション・データを格納できます。MicroTxライブラリは、LRAおよびTCCトランザクション・プロトコルではアプリケーション・データベースとやり取りすることはありません。

6.1.2 リソース・マネージャのサポートされているドライバ

使用するリソース・マネージャで機能する、正しいJDBCドライバとUCPバージョンを必要に応じて選択するのはアプリケーション開発者の責任です。

リソース・マネージャとしてのOracle Databaseの使用

Oracle Databaseで動作するJDBCドライバおよびUCPバージョンを使用する必要があります。MicroTxライブラリは、XAResourceオブジェクトにアクセスして、リソース・マネージャに対して様々なXA操作を実行します。XAResourceオブジェクトはJDBCドライバによって提供されます。

MicroTx Javaライブラリでは、パフォーマンスを向上させるために、ユニバーサル接続プール(UCP)がOracle JDBCドライバとともに使用されます。

Java用のMicroTxライブラリは、Oracle Databaseドライバのバージョン21.3.0.0でテストされています。

Oracle Databaseをリソース・マネージャおよびMicroTx Node.jsライブラリとして使用する場合は、参加側アプリケーションでnode-oracledb 6.1.0を使用する必要があります。

ロギング・ラスト・リソース(LLR)トランザクションを使用する場合、データベース・ドライバの追加要件はありません。

リソース・マネージャとしてのOracle Database以外の使用

XADataSourceおよびXAResourceインタフェースを実装する、サポートされているJDBCドライバを使用する必要があります。MicroTxライブラリは、XAResourceオブジェクトにアクセスして、リソース・マネージャに対して様々なXA操作を実行します。

6.1.3 非XAリソースの最適化

ロギング・ラスト・リソース(LLR)またはラスト・リソース・コミット(LRC)の最適化を使用すると、1つの非XAリソースがグローバル・トランザクションに参加できるようになります。

マイクロサービスには、いくつかの参加側アプリケーションが含まれることがあり、各アプリケーションが異なるリソース・マネージャに接続されている場合があります。たとえば、1つのマイクロサービスに、リソース・マネージャとしてOracle Databaseを使用するトランザクション・イニシエータ・アプリケーションと、リソース・マネージャとしてMongoDBを使用するトランザクション参加側アプリケーションが含まれるとします。MongoDBではXAプロトコルはサポートされません。しかしながら、MongoDBとOracle Databaseのどちらもグローバル・トランザクションに参加する必要があります。MicroTxでは、LLRまたはLRCの最適化を有効にすると、そのようなマイクロサービスに対してXAトランザクションプロトコルを使用できます。

ロギング・ラスト・リソース(LLR)の最適化について

LLRの最適化を使用すると、1つの非XAリソースがXAと同じACID保証を使用してグローバル・トランザクションに参加できるようになります。

XAリソースは、トランザクション・コーディネータによって送信されるXAリクエスト(準備、コミット、ロールバックなど)を処理できます。非ネイティブまたは非XAリソースは、このようなリクエストを処理できません。LLRおよびLRCの最適化によって、1つの非XAリソースがXAトランザクションに参加できるようになります。トランザクション・コーディネータは、トランザクションの他のすべてのブランチを準備してから、LLRまたはLRCブランチに対するローカル・トランザクション・コミットの実行を試みます。他のすべてのブランチが問題なく準備されていると仮定すると、ローカル・コミットの結果によってトランザクションの結果が決まります。ローカル・コミットが正常に行われると、トランザクションが正常にコミットされます。それ以外の場合はトランザクションがロールバックされます。

ローカル・コミットを実行する前に、トランザクション・コーディネータはLLRブランチにコミット・レコードを作成します。エラーが発生した場合、トランザクション・コーディネータは、LLRブランチでxa_recoverをコールしてトランザクションのリストをリカバリしようとします。LLRブランチがローカル・トランザクションを正常にコミットした場合、commitRecordによって、準備が完了した参加側のリストが返されます。LLRブランチがローカル・トランザクションのコミットに失敗した場合、recover()メソッドによって、参加側が記録されていないことを示す情報が返されます。

デフォルトでは、コミット・レコードは2時間後に削除されます。コミット・レコードが保持される期間を変更するには、oracle.tmm.LlrDeleteCommitRecordIntervalプロパティで期間を指定します。たとえば、600000ミリ秒または10分を指定すると、過去10分間に作成されたコミット・レコードのみが保持され、それ以前のレコードは削除されます。

LLRブランチが、トランザクション・コーディネータのコミット・レコードも含むローカル・トランザクションのコミットに成功した場合、recover()によってコミット・レコードが返されます。

ラスト・リソース・コミット(LRC)の最適化について

LRCの最適化を使用すると、1つの非XAリソースがXAと同じACID保証を使用せずにグローバル・トランザクションに参加できるようになります。

LRCでは、トランザクションのフローのシーケンスはLLRとほぼ同じです。イニシエータがトランザクション・コーディネータに対してcommitをコールすると、トランザクション・コーディネータはすべてのXAブランチを準備してから、LRCブランチでcommit()をコールします。唯一の違いは、エラーの場合に、commit()メソッドがNULLをLRCのcommitRecordの値として返すため、トランザクション詳細をリカバリできないことです。LLRでは、commit()メソッドによって、準備が完了した参加側のリストがレスポンスで返されます。LRCでcommit()がコールされると、ローカル・トランザクションがコミットされ、結果がトランザクション・コーディネータに返されます。ただし、準備が完了した参加側に関する情報は格納されていません。

トランザクション・ログの詳細情報が格納されないため、LRCの最適化は、サポートされているすべてのリソース・マネージャと連携します。ただし、ローカル・コミットが正常に完了したかどうかをトランザクション・コーディネータが確認する方法がないため、ヒューリスティックな結果になる可能性が高くなります。また、LRCではrecover()メソッドを使用できないため、エラーの場合にトランザクションをリカバリできません。

LLRまたはLRCの選択

エラーの場合に詳細をリカバリできるため、非XAリソースについてLLRの最適化を使用することを強くお薦めします。LRCの最適化を使用するのは、非XAリソースがcommitRecordの詳細すなわちトランザクション・ログの詳細を格納できない場合のみにしてください。

制限事項

• MicroTxでは、LLRまたはLRCの最適化を使用すると、1つの非XAリソースを含む1つの参加側アプリケーションのみが、XAトランザクションに参加できます。マイクロサービスに複数の非XAリソースがある場合、MicroTxはこのマイクロサービスのXAトランザクション・プロトコルをサポートしません。たとえば、複数のLLR参加側またはLRC参加側を使用しようとすると、エラー・メッセージOnly one LLR or LRC participant is allowed to enlistが表示されます。

イニシエータ・アプリケーションがそのトランザクションを起動した後で参加する場合は、そのイニシエータ・アプリケーションでLLRまたはLRCリソースを使用できます。

6.1.4 複数のアプリケーションの共通リソース・マネージャ

複数の参加側サービスに共通リソース・マネージャを使用する場合、MicroTxはコミット処理を最適化できるため、XAトランザクションのスループットが向上し、レイテンシが低下します。

複数の参加側サービスに共通リソース・マネージャを使用する場合は、ORACLE_TMM_XA_RMID環境変数の値を指定してトランザクションを最適化できます。リソース・マネージャを共有するすべての参加側サービスに対して1つのブランチのみが作成されるため、トランザクションは最適化されます。

部門A、部門Bおよび部門Cは、リソース・マネージャを共有するが、異なるORACLE_TMM_XA_RMID値を持つ3つの参加側サービスであるとします。MicroTxは、部門ごとに新しいブランチを作成します。MicroTxで、トランザクションを追跡するためのブランチが合計3つ作成されます。

トランザクションを最適化するには、部門A、部門Bおよび部門CサービスのORACLE_TMM_XA_RMID環境変数に、ORCL1などの一意の値を指定します。

ORACLE_TMM_XA_RMID環境変数に値を指定すると、MicroTxは単一のリソース・マネージャを使用するすべてのサービスに対して単一のブランチを作成します。複数のブランチが作成されないため、トランザクションが最適化されます。このシナリオでは、MicroTxはトランザクションを最適化し、共通のリソース・マネージャと複数の参加側が関与するトランザクションを追跡する単一のブランチを作成します。この変数に値を指定しない場合、MicroTxはトランザクションを最適化せず、参加側サービスごとに1つずつ3つのブランチを作成します。

ノート:

Oracle RACデータベースを複数の参加側サービスの共通リソース・マネージャとして使用する場合は、共通のOracle RACデータベースをリソース・マネージャとして使用するすべての参加側サービスに同じRMID値を指定する必要があります。

制限事項

• 複数の参加側サービスで共有できるのは、XA準拠のリソース・マネージャのみです。非XAリソースを複数の参加側サービスと共有することはできません。
• トランザクションに参加するイニシエータ・アプリケーションを含め、すべてのトランザクション参加側サービスに共通リソース・マネージャを使用できます。トランザクションを開始するがトランザクションに参加しないトランザクション・イニシエータ・サービスは、リソース・マネージャを必要としません。
• リソース・マネージャごとに一意のRMIDを使用する必要があります。異なるリソース・マネージャに同じRMIDを使用すると、トランザクションは失敗します。

6.1.5 1つのアプリケーションでの複数のリソース・マネージャの構成

1つの参加側サービスに対して複数のリソース・マネージャを使用できます。ビジネス・ロジックに基づいて、1つの参加側サービスは、複数のXA準拠リソース・マネージャに接続できます。ただし、1つのトランザクションで非XAリソースは1つしかサポートされません。

ノート:

この機能は、Javaアプリケーション用のMicroTxクライアント・ライブラリのみで提供されています。JPAまたはHibernateアプリケーションでは、XA準拠のリソース・マネージャのみがサポートされます。

6.1.6 XAトランザクションの動的リカバリについて

トランザクション・コーディネータ・サーバーは、障害後にサーバーが再起動したときに進行中のトランザクションを再開します。

トランザクション・コーディネータが再起動するたびに、トランザクション・ストアで使用可能なデータに基づいて、すべてのプロトコル(XA、LRAおよびTCC)のトランザクションがリカバリされます。「トランザクション・リカバリについて」を参照してください。

また、XAトランザクション・プロトコルの場合、トランザクション・コーディネータは、コミットされていないトランザクションを動的にリカバリします。トランザクション・コーディネータは、コーディネータが失敗したときに進行中のトランザクションをチェックし、コミットまたはロールバック・コマンドを発行してトランザクションを完了します。トランザクションが見つからないか、すでに完了している場合、コーディネータはリソース・マネージャからトランザクション・レコードを削除します。

動的リカバリは、指定したリソース・マネージャID (RMID)に基づいて実行されます。各リソース・マネージャに指定するRMIDが一意であることを確認します。

トランザクション・コーディネータは、RMIDに基づいてリソース・マネージャごとに1回、動的リカバリを実行します。トランザクション・コーディネータ・インスタンスを再起動すると、リカバリ済情報は失われませんが、リカバリ済RMIDリストのマッピングは失われます。動的リカバリ中、RMIDごとにxa_recoverが1回コールされます。リソース・マネージャに関するリカバリ済情報はメモリーに保持されます。参加側が登録するたびに、トランザクション・コーディネータはRMIDを、メモリーに保持されているリカバリ済リソース・マネージャ・マッピングと照合します。これにより、リカバリ済リストにRMIDが存在しない場合にのみ、xa_recoverがコールされます。リカバリ済リストにRMIDが存在する場合、xa_recoverはコールされません。リソース・マネージャ・マッピングはメモリーに保持されるため、トランザクション・コーディネータが再起動すると、リカバリ済RMIDリストのリストが失われます。このようなシナリオでは、一意のRMIDが登録されるたびにリカバリが再度コールされます。

MicroTxがトランザクション・データを格納するようetcdまたはOracle Databaseを設定した場合は、コーディネータの再起動後、進行中のトランザクションに関する情報とトランザクションの詳細を取得できます。ただし、個別のトランザクション・ストアを設定しておらず、内部メモリーを使用してトランザクション詳細を格納している場合は、コーディネータがクラッシュまたは再起動すると、格納されているすべての情報が失われます。XAは動的リカバリをサポートしているため、内部メモリーを使用している場合、動的にリカバリされるすべての(xa_recover)XAトランザクションはロールバックされ、その後にxa_forgetが続きます。