EJB コンテナー

Enterprise JavaBeans (EJB) コンテナーは、 アプリケーション・サーバー内にエンタープライズ Bean のランタイム環境を提供します。 このコンテナーは、 アプリケーション・サーバー内のエンタープライズ Bean のオペレーションのすべての側面を処理し、Bean 内のユーザー作成のビジネス・ロジックとアプリケーション・サーバー環境の残りの部分との間の仲介プログラム役として機能します。

それぞれに 1 つ以上のエンタープライズ Bean が入った、1 つ以上の EJB モジュールを単一のコンテナーにインストールできます。

EJB コンテナーは、エンタープライズ Bean に対して以下のような多くのサービスを提供します。
  • 適時のトランザクションの開始、コミット、およびロールバック。
  • 着信要求の準備ができているエンタープライズ Bean インスタンスのプールの保守および非アクティブ・プールとアクティブ状態の間でのこれらのインスタンスの移動。 これにより、Bean 内のスレッド化条件が確実に満たされます。
  • 最も重要なサービスとして、エンティティー Bean のインスタンス変数内のデータと、 永続ストレージに保管されている対応するデータ項目との自動同期化。

Bean がアクティブ状態になったり、 非アクティブ状態になったりする際に、 アクティブ Bean インスタンスの集合の保守や永続ストレージと Bean 状態との同期化を動的に行うことで、 コンテナーは、 別の方法でアプリケーション・サーバーのメモリー内に同時に保持できるよりも多くの Bean インスタンスをアプリケーションにより管理できるようにします。 この点で、EJB コンテナーは、 オペレーティング・システム内の仮想メモリーと同様のサービスを提供します。

WebSphere® Application Server を用すると、エンティティー Bean を使用したデータベース・データの管理をきわめて柔軟に行うことができます。エンティティー EJB の「Activate at」および「Load at」構成設定は、エンタープライズ Bean の対応するデータベース行データから、いつどのようにデータをロードしてキャッシュに入れるのかを指定します。 これらの構成設定により、EJB 1.1 仕様で指定されているエンタープライズ Bean のキャッシング・オプション A、B、または C を指定できます。これらの設定は、アセンブリー・ツールによって構成できます。 アセンブリー・ツールの使用方法について詳しくは、アセンブリー・ツールのインフォメーション・センターを参照してください。

1 つのトランザクションが終了して、次のトランザクションが始まるまでの間、エンティティー Bean の状態はキャッシュすることができます。 EJB コンテナーは、オプション A、B、および C のキャッシングをサポートします。
  • オプション A のキャッシングを使用する場合、 アプリケーション・サーバーは、エンティティー Bean が単一コンテナー内で使用されることを前提としています。 その Bean のクライアントは、要求をそのコンテナー内の Bean インスタンスに誘導しなければなりません。 エンティティー Bean は、 基礎をなすデータベースへの排他的なアクセスを行います。 つまり、 オプション A のキャッシングを使用すると、Bean はその複製を作成することもワークロード管理に参加することもできません。
    読み取り専用シナリオを使用する場合、製品はオプション 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 セッションについて記述されたセッション・クラスター化機能と同様です。

オプション A では、トランザクションの範囲外のデータベース・データをキャッシングすることにより、エンタープライズ Bean の最大のパフォーマンスが得られます。 通常、オプション A は、EJB コンテナーが特定のデータベースに排他的アクセスを行う場合にのみ適用できます。 それ以外の場合は、データ保全性が損なわれます。 オプション B では、エンティティー EJB オブジェクト・インスタンスをより積極的にキャッシングします。これにより、オプション C よりもパフォーマンスは向上しますが、メモリーの使用量は増加します。 オプション C は、実際に用いられているエンティティー EJB の最も一般的な構成です。これがデフォルト設定です。

Activate at」設定は、エンタープライズ Bean が活動化されてキャッシュに入れられるタイミングを指定します。 キャッシュからの除去および非活動化も、この設定によって制御されます。 有効な値は、Once および Transaction です。 Once 設定は、サーバー・プロセスで最初にアクセスされたときに Bean が活動化され、コンテナーにおける任意のタイミング (キャッシュがいっぱいになった場合など) で Bean が非活動化 (およびキャッシュから除去) されることを示します。 Transaction 設定は、トランザクションの開始時に Bean が活動化され、トランザクションの終了時に Bean が非活動化 (およびキャッシュから除去) されることを示します。 デフォルト値は Transaction です。

Load at」設定は、Bean が自身の状態をデータベースからいつロードするかを指定します。 このプロパティーの値によって、コンテナーがデータベースに排他的アクセスを行うのか、共有アクセスを行うのかが暗黙指定されます。 有効な値は、Activation および Transaction です。 Activation は、Bean を活動化する際に Bean がロードされることを示し、コンテナーがデータベースに排他的アクセスを行うことを暗黙指定します。 Transaction は、トランザクションの開始時に Bean がロードされることを示し、コンテナーがデータベースに共有アクセスを行うことを暗黙指定します。 デフォルトは Transaction です。「Activate at」プロパティーおよび「Load at」プロパティーの設定により、どのコミット・オプションを使用するかが制御されます。 オプション A (データベースへの排他的アクセス) の場合は、Activate at = Once および Load at = Activation を使用します。 このオプションを使用すると、ejbLoad 関数の呼び出しが行われないため、データベースの入出力が減りますが、Bean インスタンスにアクセスするすべてのトランザクションがシリアライズされます。 オプション A では、キャッシュ内に保持されるオブジェクトの数が多くなるためにメモリーの使用量が増加する可能性がありますが、通常、Bean インスタンスに複数のトランザクションが同時にアクセスすることがなければ、応答時間を短縮することができます。
重要: WebSphere WebSphere Application Server Network Deployment を使用し、ワークロード管理が使用可能になっている場合、オプション A を使用することはできません。

結果的にオプション B または C が使用される設定を使用する必要があります。オプション B (データベースへの共有アクセス) の場合は、Activate at = Once および Load at = Transaction を使用します。オプション B では、キャッシュ内に保持されるオブジェクトの数が多くなるためにメモリーの使用量が増加する可能性があります。 しかし、トランザクションごとに独自のオブジェクトのコピーが作成されるため、1 つのインスタンスの複数のコピーが (トランザクションごとに 1 つずつ) 同時にメモリー内に存在し、トランザクションごとにデータベースにアクセスする必要が生じることがあります。 エンタープライズ Bean に非常に多くの ejbActivate 関数の呼び出しが含まれている場合、オプション B を使用すると、必要なオブジェクトが既にキャッシュに入っているため、効果的な場合があります。 それ以外の場合、このオプションにオプション A よりも大きな利点はありません。オプション C (データベースへの共有アクセス) の場合は、Activate at = Transaction および Load at = Transaction を使用します。 このオプションでは、キャッシュ内に保持されるオブジェクトの数が少なくなるためにメモリーの使用量を削減することができます。 しかし、1 つのインスタンスの複数のコピーが (トランザクションごとに 1 つずつ) 同時にメモリー内に存在することがあります。 このオプションを使用すると、同時にアクセスされることはあるが更新されることはないエンタープライズ Bean インスタンスに関するトランザクションの競合を削減することができます。

この製品は、 複数のアプリケーション・サーバー間のステートフル・セッション Bean ホーム・オブジェクトのクローン作成をサポートしています。 ただし、ステートフル・セッション Bean の特定のインスタンスのクローン作成はサポートしていません。 特定のステートフル・セッション Bean の各インスタンスは、1 つのアプリケーション・サーバー内だけで存在でき、 要求をその特定のアプリケーション・サーバーに誘導することによってのみアクセスできます。 ステートフル・セッション Bean の状態情報は、 サーバー・クラスターの複数メンバー間で保持することはできません。 ただし、ステートフル・セッション Bean のフェイルオーバーを使用可能にし、EJB コンテナーでメモリー間複製を使用するよう構成することにより、ステートフル・セッション Bean のフェイルオーバーがクラスター内の他のサーバーに複製され、ステートフル・セッション Bean の 1 次サーバーが何らかの理由で停止した場合に、バックアップ・サーバーでフェイルオーバーが行われます。ステートフル・セッション Bean のフェイルオーバーについて詳しくは、『EJB コンテナー用ステートフル・セッション Bean のフェイルオーバー』を参照してください。

デフォルトで、EJB コンテナーは「quick start」モードで稼働します。EJB コンテナーの始動ロジックは、メッセージ駆動型 Bean (これらにメッセージが通知される前にメッセージ駆動型 Bean が存在する必要があるため)、開始 Bean (サーバー始動時に処理される必要があるため)、およびサーバー始動時に初期化されるよう指定する EJB タイプを除く、すべての EJB タイプのロードおよび処理を遅らせます。 .

その他すべての EJB 初期化は、最初に EJB が使用されるまで遅れます。 ローカル・インターフェースを使用する場合、最初に使用するのは、そのタイプに InitialContext.lookup メソッドを実行するときです。 リモート・インターフェースの場合は、EJB またはそのホームで最初のメソッドを呼び出すときです。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_ecnt
ファイル名:cejb_ecnt.html