このプロジェクトでは、Oracle XA 接続プールを使用します。クエリ (トランザクション) の小さなサブセットのみが分散されます。残りは、非常に単純な単一データベースの変更です。
XAConnections と通常のものを使用する際にパフォーマンスの違いがあるかどうかを知りたいです。
サーバーとして websphere v6.1 を使用します。
XAConn のパフォーマンスがあまり高くない場合は、2 つのデータソースを用意し、それらからの接続を適切に使用することを計画しています。
どんなポインタでも大いに役立ちます。
以下を実証するベンチマークはありません。これは、「私たちは皆、それを知っている」という従来の通念にすぎません。すべてのパフォーマンスの議論と同様に、マイレージは変動します。これがアプリケーションにとって絶対に重要である場合は、独自のベンチマークを実行する必要があります。
XA 以外の作業に XA 対応の接続プールを使用しても、重大なパフォーマンス オーバーヘッドはないと考えています。WebSphere は、トランザクションで単一のリソースのみが使用される場合、1PC トランザクションを慎重に使用します。XA の主なオーバーヘッドは、追加の XA メッセージの Prepare/Commit/Forget セットです。これらは単純な 1PC ケースでは発生しません。
したがって、主な危険は、不注意に 2PC トランザクションを開始することです。これは、おそらく同じリソースに対していくつかの作業を行うが、(たとえば) 異なる分離レベルを使用する場合に発生する可能性があります。プールから接続を取得して何らかの作業を行うと、その接続は COMMIT までトランザクションに関連付けられます。接続を「閉じて」、概念的にはプールに戻しますが、実際には WebSphere のプーリングがトランザクションの接続を保持します。まったく同じ接続を要求している場合、さらに作業を行うために接続を再度要求します。同じ接続が再度与えられるため、単一のトランザクションで作業が続行されます。1PC しかなく、オーバーヘッドはありません。
最初は XA 対応のプールを 1 つ持つアプローチを取りますが、2PC 作業用と 1PC 作業用の 2 つの別個のリソース参照を用意します。両方の参照が同じ接続プールを指すようにします。コードは、個別の接続プールを持つ必要性から分離されました。変更を行う必要がある場合は、resource-ref を再バインドするだけです。