WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
|
 |
 |
|
この節では、セッション Bean が EJB コンテナの中でどのように機能するのかを説明し、セッション Bean に固有の設計および開発ガイドラインも提供します。Bean 開発の全体的なプロセスについては、「エンタープライズ JavaBean の実装」を参照してください。
この章は、Java のプログラミングおよびセッション Bean の機能に精通している読者を対象としています。セッション Bean の機能の概要およびセッション Bean のアプリケーションでの典型的な使用方法については、「セッション EJB によるビジネス ロジックの実装」および「セッション Bean の機能」を参照してください。
以下の節では、セッション Bean のライフサイクル、設計上の考慮事項、および主要な実装タスクの手順について説明します。
この節では、ステートレス セッション Bean とステートフル セッション Bean の主な違いについて説明します。
表 5-1 ステートレス セッション Bean とステートフル セッション Bean の比較
どのタイプのセッション Bean をいつ使用するのかについては、「ステートレス Bean とステートフル Bean の選択」を参照してください。
デフォルトでは、WebLogic Server には起動時にステートレス セッション EJB インスタンスは存在しません。個々の Bean が呼び出されると、WebLogic Server は EJB の新しいインスタンスを初期化します。
ただし、プロダクション環境では、WebLogic Server は非バインド ステートレス セッション EJB (現在メソッド呼び出しを処理していないインスタンス) のフリー プールを使用することでステートレス セッション EJB のパフォーマンスとスループットを向上させることができます。リクエストの処理に利用できる非バインド インスタンスがある場合は、リクエストがインスタンスの作成を待つ必要がないので応答時間が向上します。フリー プールは、できる限りオブジェクトの再利用やコンテナ コールバックのスキップをすることでパフォーマンスを改善しています。
WebLogic Server は起動時に、自動的にフリー プールを作成し、weblogic-ejb-jar.xml ファイルの Bean のデプロイメント要素 initial-beans-in-free-pool で指定された量のインスタンスをそのプールに配置します。デフォルトでは、initial-beans-in-free-pool は 0 に設定されています。
次の図に、WebLogic Server のフリー プールと、ステートレス EJB がフリー プールに出入りするプロセスを示します。点線は、WebLogic Server 側から見た EJB の「状態」を表しています。
図 5-1 ステートレス セッション EJB のライフサイクルを示す WebLogic Server フリー プール
プールをコンフィグレーションした場合、WebLogic Server はフリー プールの EJB インスタンス (利用可能な場合) を利用してメソッド呼び出しに対応します。EJB は、クライアントのメソッド呼び出しの間アクティブ状態になります。メソッドが完了すると、EJB のインスタンスはフリー プールに戻されます。WebLogic Server は各メソッドの呼び出し後にクライアントからステートレス セッション Bean を非バインドするので、クライアントが使用する実際の Bean クラスは呼び出しごとに異なります。
EJB クラスのすべてのインスタンスがアクティブで、max-beans-in-free-pool に達した場合、EJB クラスを要求する新しいクライアントは、アクティブ EJB がメソッド呼び出しを完了するまでブロックされます。トランザクションがタイムアウトになった場合 (トランザクション非対応の呼び出しでは、5 分経過した場合)、WebLogic Server は、リモート クライアントに対しては RemoteException を、ローカル クライアントに対しては EJBException を送出します。
注意 : フリー プールの最大サイズは、max-beans-in-free-pool 要素の値、使用可能メモリ、または実行スレッドの数によって制限されます。
アプリケーションがフリー プールの Bean インスタンスを要求した場合には、以下の 3 通りの結果が考えられます。
max-beans-in-free-pool に達していない。WebLogic Server は新しい Bean インスタンスを割り当てて、それを提供します。max-beans-in-free-pool に達している。トランザクションがタイムアウトになるか、プール内の既存の Bean インスタンスが使用可能になるまで待機する必要があります。
WebLogic Server は、Bean インスタンスのキャッシュを使用してステートフル セッション EJB のパフォーマンスを高めます。キャッシュはメモリ内にアクティブな EJB インスタンスを格納することで、それらをクライアント リクエストに即座に使用できるようにしています。キャッシュには、クライアントによって現在使用されている EJB と最近使われていたインスタンスが格納されます。キャッシュ内のステートフル セッション Bean は、特定のクライアントと結び付いています。
次の図に、WebLogic Server のキャッシュと、ステートフル EJB がキャッシュに出入りするプロセスを示します。
図 5-2 ステートフル セッション EJB のライフサイクル
WebLogic Server には起動時にステートフル セッション EJB インスタンスは存在しません。クライアントがステートフル セッション Bean へのアクセスを開始する前に、Bean とのセッションで使用する新しい Bean インスタンスが作成されます。セッションが終了すると、インスタンスは破棄されます。セッションが進行中の間は、インスタンスはメモリにキャッシュされます。
パッシベーションは、EJB の状態をディスク上で保持しつつキャッシュからその EJB インスタンスを削除するために WebLogic Server が使用するプロセスです。パッシブ化されている EJB はメモリには存在せず、キャッシュに格納されているときのようにクライアント リクエストに応じて即座に使用することはできません。
EJB 開発者は、ejbPassivate() メソッドが呼び出されたときに、ステートフル セッション Bean が、WebLogic Server によってそのデータがシリアライズされてそのインスタンスのパッシベーションが行われるような状態に置かれるようにしなければなりません。パッシベーションの間、WebLogic Server は transient であると宣言されていないフィールドをシリアライズしようとします。つまり、すべての非 transient フィールドがシリアライズ可能なオブジェクト (Bean のリモートまたはホーム インタフェースなど) を表すようにしなければなりません。EJB 2.1 では、許可されるフィールド タイプが指定されています。
ステートフル セッション Bean のパッシベーションを制御するルールは、Bean の cache-type 要素の値によって決まります。この要素の値は以下のいずれかです。
idle-timeout-seconds 要素と max-beans-in-cache 要素も、cache-type の値に基づいてパッシベーションと削除の動作に影響を与えます。
cache-type を LRU に設定してステートフル セッション Bean の積極的なパッシベーションをコンフィグレーションすると、コンテナは以下のようにしてインスタンスをディスクにパッシベーションします。
max-beans-in-cache の値に関係なく、インスタンスの非アクティブな状態が idle-timeout-seconds の期間を経過するとすぐ idle-timeout-seconds が経過していなくても、max-beans-in-cache に達したときコンテナは、パッシベーションされたインスタンスを、そのパッシベーション後、idle-timeout-seconds の期間非アクティブな状態が続いた後にディスクから削除します。この動作は、怠惰な削除と呼ばれます。
cache-type を NRU に設定して怠惰なパッシベーションをコンフィグレーションすると、関連するシステムのオーバーヘッドが原因でコンテナは Bean のパッシベーションを回避します (キャッシュに影響を与えるのは、Bean のパッシベーションまたは積極的な削除を引き起こすイベントのみとなります)。
idle-timeout-seconds が経過したときにキャッシュから Bean のインスタンスを削除し、それをディスクにパッシベーションすることはしない。この動作は、積極的な削除と呼ばれます。積極的な削除を行うと、アクティブでないインスタンスによってメモリまたはディスクのリソースが消費されなくなります。 idle-timeout-seconds が経過していなくても、max-beans-in-cache に達したときにインスタンスをディスクにパッシベーションする。プロダクション環境でパフォーマンスを最適化するキャッシュ サイズの管理については、『WebLogic Server パフォーマンス チューニング ガイド』の「ステートフル セッション Bean とエンティティ Bean のキャッシュ サイズの設定」を参照してください。
ステートフル セッション Bean がパッシベーションされると、その状態がファイル システムのディレクトリに格納されます。各サーバ インスタンスには、パッシベーションされたステートフル セッション Bean の状態を格納する専用のディレクトリ (永続ストア ディレクトリ) があります。永続ストア ディレクトリは、パッシベーションされた Bean ごとに 1 つのサブディレクトリを格納します。
永続ストア ディレクトリは、たとえば次のようにサーバ インスタンスのディレクトリにデフォルトで作成されます。
D:\releases\610\bea\user_domains\mydomain\myserver\pstore\
RootDirectory\ServerName\persistent-store-dir
D:\releases\810\bea\user_domains\mydomain
RootDirectory は、-Dweblogic.RootDirectory プロパティを使用してサーバの起動時に指定できます。
weblogic-ejb-jar.xml の <stateful-session-descriptor> スタンザの persistent-store-dir 要素の値。<persistent-store-dir> の値が指定されていない場合、ディレクトリの名前はデフォルトで pstore になります。永続ストア ディレクトリには、パッシベーションされた各 Bean 用のサブディレクトリ (ハッシュ コードで命名される) が格納されます。たとえば、上の例のパッシベーションされた Bean のサブディレクトリは次のようになります。
D:\releases\810\bea\user_domains\mydomain\myserver\pstore\14t89gex0m2fr
EJB 2.0 仕様によると、ステートフル セッション EJB に同時アクセスすると RemoteException が送出されます。ステートフル セッション EJB に関するこのアクセス制限は、EJB クライアントが WebLogic Server の内部にあるのかそれともリモートにあるのかに関係なく適用されます。この制限を無効にして、同時呼び出しが可能なようにステートフル セッション Bean をコンフィグレーションするには、allow-concurrent-calls デプロイメント要素を設定します。
複数のサーブレット クラスがステートフル セッション EJB にアクセスする場合は、サーブレット クラスのインスタンスごとではなくサーブレット スレッドごとに独自のセッション EJB インスタンスを使用する必要があります。同時アクセスを避けるために、JSP またはサーブレットはリクエスト スコープでステートフル セッションを使用できます。
この節では、セッション Bean に関連するいくつかの設計上の決定について説明します。
ステートレス セッション Bean は、アプリケーションでビジネス メソッドの呼び出しの間に特定クライアントの状態を保持する必要がない場合は適切な選択肢です。WebLogic Server はマルチスレッドで、複数のクライアントに同時にサービスを提供します。ステートレス セッション Bean を使用した場合、EJB コンテナはセッションの間各クライアントのインスタンスを確保するのではなく、プールにある利用可能な Bean インスタンスを自由に利用してクライアント リクエストに応えることができます。その結果、リソースの使用率、スケーラビリティ、およびスループットが向上します。
ステートレス セッション Bean のメリットは、その実装が軽量であることです。ステートレス セッション Bean は、アプリケーションの Bean が Bean 同士の対話なく独立した別個のタスクを実行する場合に優れた選択肢となります。
ステートフル セッション Bean は、セッションが終わるまで Bean の状態を保持する必要がある場合に良い選択肢です。
ステートレス セッション Bean とステートフル セッション Bean のアプリケーションの例については、「ステートレス セッション Bean」および「ステートフル セッション Bean」を参照してください。
initial-beans-in-free-pool および max-beans-in-free-pool の値を選択するときには、メモリ消費とアプリケーションの速度低下を天秤にかけて検討する必要があります。ステートレス セッション Bean インスタンスの数が多すぎると、フリー プールにメモリを消費する非アクティブなインスタンスが格納されます。数が少なすぎると、クライアントは必要なときにインスタンスを取得できない場合があります。その場合は、インスタンスが解放されるまでクライアント スレッドがブロックされて、アプリケーションの速度が低下します。
通常、max-beans-in-free-pool はサーバ インスタンスのワーカ スレッドと同数にします。そうすれば、スレッドが処理を試みるときに、インスタンスが利用可能な状態にあります。
「エンタープライズ JavaBean の実装」では、セッション Bean 実装の手順が説明されています。この節では、Bean 固有のデプロイメント記述子要素を設定して WebLogic Server 固有のセッション Bean の動作をコンフィグレーションする詳細について説明します。
表 5-2 では、ステートレス セッション Bean の動作をコンフィグレーションするために設定するデプロイメント記述子要素について、および要素をコンフィグレーションしない場合の Bean の動作についてまとめられています。リストされている要素はすべて、weblogic-ejb-jar.xml の stateless-session-descriptor 要素のサブ要素です。
表 5-3 では、ステートレス セッション Bean の動作をコンフィグレーションするために設定するデプロイメント記述子要素について、および要素をコンフィグレーションしない場合の Bean の動作についてまとめられています。リストされている要素はすべて、weblogic-ejb-jar.xml の stateful-session-descriptor 要素のサブ要素です。
表 5-2 ステートレス セッション EJB の WebLogic 固有の機能
|
|
||
|
|
表 5-3 ステートフル セッション EJB の WebLogic 固有の機能
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
|
|
|