Enterprise JavaBeans (EJB) コンテナーは、
アプリケーション・サーバー内にエンタープライズ Bean のランタイム環境を提供します。
このコンテナーは、
アプリケーション・サーバー内のエンタープライズ Bean のオペレーションのすべての側面を処理し、Bean 内のユーザー作成のビジネス・ロジックとアプリケーション・サーバー環境の残りの部分との間の仲介プログラム役として機能します。
それぞれに 1 つ以上のエンタープライズ Bean が入った、1 つ以上の EJB モジュールを単一のコンテナーにインストールできます。
EJB コンテナーは、エンタープライズ Bean に対して以下のような多くのサービスを提供します。
- 適時のトランザクションの開始、コミット、およびロールバック。
- 着信要求の準備ができているエンタープライズ Bean インスタンスのプールの保守および非アクティブ・プールとアクティブ状態の間でのこれらのインスタンスの移動。
これにより、Bean 内のスレッド化条件が確実に満たされます。
- 最も重要なサービスとして、エンティティー Bean のインスタンス変数内のデータと、
永続ストレージに保管されている対応するデータ項目との自動同期化。
Bean がアクティブ状態になったり、
非アクティブ状態になったりする際に、
アクティブ Bean インスタンスの集合の保守や永続ストレージと Bean 状態との同期化を動的に行うことで、
コンテナーは、
別の方法でアプリケーション・サーバーのメモリー内に同時に保持できるよりも多くの Bean インスタンスをアプリケーションにより管理できるようにします。
この点で、EJB コンテナーは、
オペレーティング・システム内の仮想メモリーと同様のサービスを提供します。
1 つのトランザクションが終了して、次のトランザクションが始まるまでの間、エンティティー Bean の状態はキャッシュすることができます。
EJB コンテナーは、オプション A、B、および C のキャッシングをサポートします。
- オプション A のキャッシングを使用する場合、
アプリケーション・サーバーは、エンティティー Bean が単一コンテナー内で使用されることを前提としています。
その Bean のクライアントは、要求をそのコンテナー内の Bean
インスタンスに誘導しなければなりません。
エンティティー Bean は、
基礎をなすデータベースへの排他的なアクセスを行います。
つまり、
オプション A のキャッシングを使用すると、Bean はその複製を作成することもワークロード管理に参加することもできません。
読み取り専用シナリオを使用する場合、WebSphere Application Server は、
オプション A のエンティティー Bean の代わりとなる高性能な方法を提供します。このキャッシング・オプションは、
マルチスレッド読み取り専用 と呼ばれます。標準のオプション A の振る舞い同様、
EJB コンテナーは 1 度だけ Bean をアクティブ化し、EJB コンテナーがそのアクティブなインスタンス・キャッシュにスペースが必要になるまでアクティブなままにしておきます。
ただし、EJB コンテナーは、以下の振る舞いの点で標準のオプション A とは異なります。
- 最後に Bean がロードされてから永続ストレージに行われた可能性のある変更点を選択するために、
メソッドを呼び出すユーザーに対応して、永続ストレージから Bean の状態を定期的に再ロードします。
Bean のデプロイメント記述子の 再ロード間隔 設定を介してこの機能を構成することができます。
詳しくは、読み取り専用エンティティー Bean の開発
を参照してください。
- EJB コンテナーはトランザクションの最後に Bean の状態を永続ストアに書き込まず、
Bean の ejbStore() メソッドは呼び出されません。
- EJB コンテナーは、同じ Bean インスタンスで複数のクライアント (スレッド) からメソッド呼び出しを許可します。
これは、Bean 内部用の、標準 EJB コンポーネントとは異なります。
この点を踏まえて、Bean を作成する必要があり、Bean のビジネス・メソッドのロジックは全体的にスレッド・セーフでなければなりません。
- オプション B のキャッシングでは、
エンティティー Bean は、トランザクションの間キャッシュ内でアクティブな状態のままですが、
各メソッド呼び出しの開始時に再ロードされます。
- オプション C のキャッシング (デフォルト) では、
エンティティー Bean は、各トランザクションの開始時に常にデータベースから再ロードされます。
クライアントは、Bean をホストするように構成された任意のコンテナー上で、
その Bean にアクセスし、新規トランザクションの開始を試みることができます。
これは、
要求されたときに任意のサーバーからアクセス可能な共用データベースでエンティティー Bean の状態が維持されるという点で、HTTP セッションについて記述されたセッション・クラスター化機能と同様です。
この製品は、
複数のアプリケーション・サーバー間のステートフル・セッション Bean ホーム・オブジェクトのクローン作成をサポートしています。
ただし、ステートフル・セッション Bean の特定のインスタンスのクローン作成はサポートしていません。
特定のステートフル・セッション Bean
の各インスタンスは、1 つのアプリケーション・サーバー内だけで存在でき、
要求をその特定のアプリケーション・サーバーに誘導することによってのみアクセスできます。
ステートフル・セッション Bean の状態情報は、
サーバー・クラスターの複数メンバー間で保持することはできません。
ただし、ステートフル・セッション Bean のフェイルオーバーを使用可能にし、EJB
コンテナーでメモリー間複製を使用するよう構成することにより、ステートフル・セッション Bean のフェイルオーバーがクラスター内の他のサーバーに複製され、ステートフル・セッション Bean の
1 次サーバーが何らかの理由で停止した場合に、バックアップ・サーバーでフェイルオーバーが行われます。ステートフル・セッション Bean のフェイルオーバーについて詳しくは、EJB コンテナー用ステートフル・セッション Bean のフェイルオーバー
を参照してください。
デフォルトで、EJB コンテナーは「quick start」モードで稼働します。EJB コンテナーの始動ロジックは、
メッセージ駆動型 Bean (これらにメッセージが通知される前に存在する必要があるため)、
開始 Bean (サーバー始動時に処理される必要があるため)、サーバー始動時に初期化されるよう指定する EJB タイプ
以外 のすべての EJB タイプのロードおよび処理を遅らせます。
EJB タイプのクイック・スタートを使用不可にするには、詳しくは、エンタープライズ Bean タイプを変更し、Application Server Toolkit を使用してアプリケーション開始時に初期化する
を参照してください。
その他すべての EJB 初期化は、最初に EJB が使用されるまで遅れます。
ローカル・インターフェースを使用する場合は、最初に使用されるのは、そのタイプに InitialContext.lookup() メソッドを
実行するときです。
リモート・インターフェースの場合は、EJB またはホームで最初のメソッドを呼び出すときです。
EJB コンテナーの詳細については、エンタープライズ Bean: 学習用リソース
を参照してください。