5

@EJB アノテーションの使用中に発生する可能性のあるパフォーマンスの問題に関連する質問があります。次のシナリオを想像してください

public class MyBean1 implements MyBean1Remote{
 @EJB
 private MyBean2Remote myBean2;
 @EJB
 private MyBean2Remote myBean3;
 ...
 @EJB
 private MyBean20Remote myBean20;
}

他の Bean に多くの依存関係を持つ Bean があります。EJB 仕様によると、MyBean1Remote を他の Bean に注入したい場合、コンテナーはプールから必要なすべての依存関係を取得し、それを MyBean1Remote に注入してから、MyBean1Remote スタブへの参照を注入する必要があります。

したがって、次のシナリオでは、コンテナーは 20 個の ejbs (myBean1 とその 19 個の依存関係) を予約する必要があります。

public class MyAnotherBean implement MyAnotherRemote{
  @EJB
  private MyBean1Remote myBean1
}

ほとんどの場合、myBean1 の各ビジネス メソッドごとに 1 つの依存関係のみを使用するとします。その結果、その Bean を注入するたびに、コンテナーに多くの不要な EJB を強制的に予約させます。また、リモート Bean で操作していると仮定すると、依存する Bean を注入する前に、おそらくコンテナーも負荷分散アルゴリズムを実行する必要があります。

質問:

  1. クラスタ環境で運用している場合、不要なリソース予約などの過剰なパフォーマンスの問題が発生することはありませんか?

  2. このアプローチでは、本当に必要なときに特定の EJB を要求するため、古き良き ServiceLocator の方が優れたソリューションになる可能性があります。

4

2 に答える 2

12

コンテナは EJB のインスタンスを注入しません。目的のインターフェイスを実装する軽量のコンテナー生成プロキシ オブジェクトのインスタンスを挿入します。

public class MyBean1 implements MyBean1Remote {
   ...
}

public class MyAnotherBean implement MyAnotherRemote {
   @EJB
   private MyBean1Remote myBean1;
}

あなたの例では、 MyAnotherBean.myBean1 に MyBean1Remote インターフェースを実装するプロキシ オブジェクトが注入されます。

ステートレスセッション Beanを想定すると(プーリングについて言及しているため)、プロキシでメソッドが呼び出されるまで、コンテナーはメソッド対応プールから実際の EJB インスタンスを割り当てず、インスタンスはプロキシ メソッド呼び出しが戻る前にプールに返されます。 .

于 2011-01-22T08:06:46.313 に答える
5

ほとんどの場合、特にステートレス セッション Bean を使用する場合、Bean インスタンスはプールされます。プーリングの背後にある理論的根拠の 1 つは、依存性注入ルックアップが比較的高価である可能性があるため、Bean は既に注入されたすべての依存性 (のスタブ) でプールされることです。

したがって、 でメソッドを呼び出すたびにMyAnotherBean、20 の推移的な依存関係を持つこの Bean は、その場で解決されたすべての依存関係で作成されるわけではありません。代わりに、完全にインスタンス化されたインスタンスがプールから選択され、メソッド呼び出しがそれに向けられます。

また、JNDI フェデレーションを行っていない限り、通常はリモート EJB を簡単に注入できないことにも注意してください。

于 2011-01-22T00:23:58.420 に答える