3

JCA リソース アダプタを作成しています。また、JCA 仕様の接続管理部分を完全に理解しようとしています。思考実験として、このアダプターの唯一のクライアントが、別のマシンにある Swing Java アプリケーション クライアントであるとします。また、リソース アダプタは、ネットワークを介して「エンタープライズ情報システム」(EIS) とも通信すると仮定します。

JCA 仕様を理解しているので、.rar ファイルはアプリケーション サーバーにデプロイされます。アプリケーション サーバーは、ManagedConnectionFactory インターフェースの .rar ファイルの実装を作成します。次に、コネクション ファクトリを生成するように要求します。コネクション ファクトリは、ユーザーがリソースへの接続を取得するために使用する JNDI にデプロイされる不透明なオブジェクトです。(JDBC の場合、接続ファクトリーは javax.sql.DataSource です。)

接続ファクトリは、アプリケーション サーバーが提供する ConnectionManager への参照を保持する必要があります。これは、直列化可能である必要があります。これは理にかなっています。コネクション ファクトリを JNDI に格納するには、シリアライズ可能である必要があり、ConnectionManager への参照を維持するには、ConnectionManager もシリアライズ可能である必要があります。この小さなオブジェクト グラフは、アプリケーション クライアントの JNDI ツリーにインストールされます。

これが私が吐き始めるところです。ConnectionManager (接続管理、共有、プーリングなどを処理することになっているアプリケーション サーバーによって提供される部分) は、この時点で完全にクライアントに存在しますか? そのジョブの 1 つは ManagedConnection インスタンスを作成することであり、ManagedConnection は Serializable である必要はなく、それが提供するユーザー接続ハンドルも Serializable である必要はありません。これは、接続プーリング機構全体がアプリケーション クライアントに大量に出荷され、その JNDI ツリーに詰め込まれていることを示唆しています。

これはすべて、クライアント側からの JCA 対話がアプリケーション サーバーのサーバー側コンポーネントをバイパスすることを意味するのでしょうか? JCA API のネットワーク境界はどこにありますか?

4

1 に答える 1

1

これはすべて、クライアント側からの JCA 対話がアプリケーション サーバーのサーバー側コンポーネントをバイパスすることを意味するのでしょうか? JCA API のネットワーク境界はどこにありますか?

私の知る限り、はい。ローカル JNDI があり、ローカル JNDI はローカル接続を返します。構成値 ( ) など、JNDI 内の他の種類のオブジェクトについて true の場合も同様ですenv-entry。もちろん、EJB をルックアップすると、ファクトリはリモート Bean にプロキシを返しますが、JNDI は私の知る限りローカルのままです。

クライアントは独自のプールを組み込みます。これは、ご指摘のとおり、クライアントで取得された接続がサーバー側の機構を回避することを意味します。

分散トランザクションをいじり始めると、さらに悪化します。UserTransactionクライアントは、クライアント側で分散トランザクションを開始および停止するために を取得できます (ただし、すべてのアプリケーション サーバーがこれをサポートしているわけではありません)。トランザクション コンテキストは、リモート EJB の呼び出し中に伝播されます。分散トランザクションは、クライアント側の接続とサーバー側の接続にまたがることがあります。

J2EE の考え方によれば、アプリケーション クライアントは通常、トランザクションを使用して接続を直接取得するべきではありません。リモート EJB とのみ通信する必要があります。

仕様は、より複雑なシナリオについて明確ではなく、それほど多くの情報もありません。たとえば、この仕様では、アプリケーション サーバーが をUserTransactionクライアントに公開することを義務付けていません。

ここに書いたことは、少なくとも Glassfish には当てはまりますが、すべてのアプリケーション サーバーでこのような機能を一貫して実装することに依存するつもりはありません。

于 2010-03-16T09:11:32.700 に答える