パフォーマンスに関連するすべてのものと同様に、答えは次のとおりです。それは状況によって異なります。具体的には、ドライバーの使用方法によって異なります。
データベースとトランザクションでやり取りするコストは、コードの複雑さのオーバーヘッド、通信のオーバーヘッド、SQL処理、およびディスクI/Oに大別されます。
XAの場合とXA以外の場合では、通信のオーバーヘッドが多少異なります。他のすべてが等しい場合、XAトランザクションは、データベースへのより多くのラウンドトリップを必要とするため、ここではもう少しコストがかかります。手動コミットモードの非XAトランザクションの場合、コストは少なくとも2つの呼び出し（SQL操作とコミット）です。 XAの場合、開始、SQL操作、終了、準備、およびコミットです。開始、SQL操作、終了、準備を自動的に最適化する特定のユースケースの場合。すべての呼び出しのコストが同じであるとは限りません。通常、結果セットで移動されるデータが支配的です。 LANでは、追加の往復のコストは通常重要ではありません。
ただし、不注意を待つために潜んでいるいくつかの興味深い落とし穴があることに注意してください。たとえば、一部のドライバーはXAモードでのプリペアドステートメントのキャッシュをサポートしていません。つまり、XAを使用すると、呼び出しごとにSQLを再解析するオーバーヘッドが追加されるか、ドライバーの上に別のステートメントプールを使用する必要があります。プールのトピックでは、XA接続を正しくプールすることは、非XA接続をプールすることよりも少し複雑なので、接続プールの実装によっては、そこでもわずかなヒットが見られる場合があります。一部のORMフレームワークは、積極的な接続解放を使用し、トランザクションスコープ内で再取得する場合、接続プールのオーバーヘッドに対して特に脆弱です。可能であれば、プールを複数回ヒットするのではなく、txの存続期間中接続を取得して保持するように構成します。
プリペアドステートメントのキャッシングに関して前述した警告がありますが、XAと非XAtxの間でSQL処理のコストに重要な違いはありません。ただし、dbサーバーのリソース使用量にはわずかな違いがあります。XA以外の場合、サーバーがリソースをより早く解放できる場合があります。ただし、トランザクションは通常十分に短いため、これは重要な考慮事項ではありません。
ここで、ディスクI/Oのオーバーヘッドについて検討します。ここでは、ビジネスロジックに使用されるSQLではなくXAプロトコルによって発生するI / Oに関心があります。後者は、どちらの場合も変更されないためです。読み取り専用トランザクションの場合、状況は単純です。賢明なdbおよびtxマネージャーはログ書き込みを行わないため、オーバーヘッドは発生しません。書き込みの場合、XAの1フェーズコミットの最適化により、dbが関係する唯一のリソースである場合にも同じことが言えます。 2PCの場合、各データベースサーバーまたは他のリソースマネージャーには、非XAの場合に使用されるディスク書き込みの代わりに2つのディスク書き込みが必要であり、txマネージャーにも同様に2つのディスク書き込みが必要です。ディスクストレージの速度が遅いため、これがXAと非XAのパフォーマンスオーバーヘッドの主な原因です。
数段落前に、コードの複雑さについて説明しました。 XAは、非XAよりもわずかに多くのコード実行を必要とします。ほとんどの場合、複雑さはトランザクションマネージャーに埋もれていますが、必要に応じてXAを直接駆動することもできます。コストはほとんどが取るに足らないものですが、すでに述べた警告があります。特に貧弱なトランザクションマネージャを使用している場合を除き、その場合は問題が発生する可能性があります。読み取り専用の場合は特に興味深いです。トランザクションマネージャープロバイダーは通常、ディスクI / Oコードに最適化の努力を注ぎますが、ロックの競合は、特に同時性の高いシステムでの読み取り専用のユースケースではより重要な問題です。
また、txマネージャーのコードの複雑さは、アプリサーバーやその他の標準的なトランザクションマネージャープロバイダーを備えたアーキテクチャでは、XAと非XAのトランザクション調整にほぼ同じコードを使用するため、やっかいなものです。 XA以外の場合、txマネージャーを完全に見逃すには、通常、アプリサーバー/フレームワークに接続を非トランザクションとして処理し、JDBCを使用して直接コミットを実行するように指示する必要があります。
つまり、概要 は次のとおりです。XA/非XAの選択に関係なく、SQLクエリのコストが読み取り専用のトランザクション時間を支配します 、構成で何かを台無しにするか、各txで特に些細なSQL操作を行わない限り、後者は、ビジネスロジックが、各txのビジネスロジックに対するtx管理オーバーヘッドの比率を変更するために何らかの再構築を使用する可能性があることを示しています。
>したがって、読み取り専用の場合は、通常のトランザクションプロトコルにとらわれないアドバイスが適用されます。毎回DBにアクセスするのではなく、ORMソリューションでトランザクション対応レベルの第2レベルのキャッシュを検討してください。それができない場合は、SQLを調整してから、ヒット率が90％以上になるか、サーバーのRAMスロットが最大になるまで、データベースのバッファキャッシュを増やします。 XAと非XAについて心配するのは、それを実行して、物事がまだ遅すぎることに気付いた場合のみです。