Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
戻る |
次へ |
この章では、セッション Bean が EJB コンテナの中でどのように機能するのかを説明し、セッション Bean に固有の設計および開発ガイドラインも提供します。Bean 開発の全体的なプロセスについては、「エンタープライズ JavaBean の実装」を参照してください。
この章は、Java のプログラミングおよびセッション Bean の機能に精通している読者を対象としています。セッション Bean の機能の概要およびセッション Bean のアプリケーションでの典型的な使用方法については、「セッション EJB によるビジネス ロジックの実装」および「セッション Bean の機能」を参照してください。
以下の節では、セッション Bean のライフサイクル、設計上の考慮事項、および主要な実装タスクの手順について説明します。
この節では、ステートレス セッション Bean とステートフル セッション Bean の主な違いについて説明します。
表 5-1 ステートレス セッション Bean とステートフル セッション Bean の比較
ステートレス セッション Bean | ステートフル セッション Bean |
---|---|
必要になるたびに Bean を作成するオーバーヘッドを削減するためにメモリにプールされる。WebLogic Server は必要なときに Bean のインスタンスを使用し、処理が完了したらそれをプールに戻す。 ステートレス セッション Bean は、ステートフル Bean よりも処理速度が速い。 |
各クライアントは Bean の新しいインスタンスを作成し、最終的にそれを削除する。インスタンスは、キャッシュがいっぱいの場合はディスクにパッシベーションできる。 アプリケーションは ステートフル セッション Bean は、ステートレス セッション Bean ほどのパフォーマンスは発揮しない。 |
ID がなく、クライアントとの関連もない。匿名である。 |
特定のクライアント インスタンスにバインドされる。各 Bean には暗黙の ID がある。クライアントがセッション中にステートフル セッション Bean と対話する場合、それは毎回同じオブジェクトに対して行われる。 |
持続しない。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 では、管理者は Administration Console を使用して EJB プールを必要に応じて初期化できます。初期化された EJB プールは、EJB がデプロイされた直後の状態にリセットされます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「EJB のアイドル状態の Bean のキャッシュおよびプールの初期化」を参照してください。
次の図に、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 要素の値、使用可能メモリ、または実行スレッドの数によって制限されます。 |
WebLogic Server をコンフィグレーションすることによって、プール内の Bean インスタンスが pool
要素の idle-timeout-seconds
要素で指定した期間にわたって未使用であった場合にそのインスタンスを削除できます。idle-timeout-seconds
で指定する期間にわたってプール内の Bean が未使用である場合、そのプール内の Bean は initial-beans-in-free-pool
で指定されている数まで削除されます。プール内の Bean の数は、initial-beans-in-free-pool
で指定されている数より少なくなることはありません。
アプリケーションがフリー プールの Bean インスタンスを要求した場合には、以下の 3 通りの結果が考えられます。
インスタンスがプールにある。WebLogic Server はそのインスタンスを利用可能にし、アプリケーションは処理を進めます。
使用可能なインスタンスがプールにないが、使用中のインスタンス数は max-beans-in-free-pool
に達していない。WebLogic Server は新しい Bean インスタンスを割り当てて、それを提供します。
使用可能なインスタンスがプールになく、使用中のインスタンス数が max-beans-in-free-pool
に達している。トランザクションがタイムアウトになるか、プール内の既存の Bean インスタンスが使用可能になるまで待機する必要があります。
WebLogic Server は、Bean インスタンスのキャッシュを使用してステートフル セッション EJB のパフォーマンスを高めます。キャッシュはメモリ内にアクティブな EJB インスタンスを格納することで、それらをクライアント要求に即座に使用できるようにしています。キャッシュには、クライアントによって現在使用されている EJB と最近使われていたインスタンスが格納されます。キャッシュ内のステートフル セッション Bean は、特定のクライアントと結び付いています。
次の図に、WebLogic Server のキャッシュと、ステートフル 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
要素の値によって決まります。この要素の値は以下のいずれかです。
LRU
- 最長時間未使用 (積極的なパッシベーション)
NRU
- 最近未使用 (怠惰なパッシベーション)
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
に達したときにインスタンスをディスクにパッシベーションする。
ステートフル セッション Bean がパッシベーションされると、その状態がファイル システムのディレクトリに格納されます。各サーバ インスタンスには、パッシベーションされたステートフル セッション Bean の状態を格納する専用のディレクトリ (永続ストア ディレクトリ) があります。永続ストア ディレクトリは、パッシベーションされた Bean ごとに 1 つのサブディレクトリを格納します。
永続ストア ディレクトリは、たとえば次のようにサーバ インスタンスのディレクトリにデフォルトで作成されます。
D:\releases\<version>\bea\user_domains\mydomain\myserver\pstore\
永続ストアのパスは次のとおりです。
RootDirectory\ServerName\persistent-store-dir
各要素の説明は次のとおりです。
RootDirectory
- WebLogic Server が動作するディレクトリ。
RootDirectory
は、-Dweblogic.RootDirectory
プロパティを使用してサーバの起動時に指定できます。
ServerName
- サーバ インスタンスの名前。
persistent-store-dir
- 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.x 仕様に従って、ステートフル セッション EJB に同時アクセスすると RemoteException
が送出されます。ステートフル セッション EJB に関するこのアクセス制限は、EJB クライアントが WebLogic Server の内部にあるのかそれともリモートにあるのかに関係なく適用されます。この制限を無効にして、同時呼び出しが可能なようにステートフル セッション Bean をコンフィグレーションするには、allow-concurrent-calls
デプロイメント要素を設定します。
複数のサーブレット クラスがステートフル セッション EJB にアクセスする場合は、サーブレット クラスのインスタンスごとではなくサーブレット スレッドごとに独自のセッション EJB インスタンスを使用する必要があります。同時アクセスを避けるために、JSP またはサーブレットは要求スコープでステートフル セッション Bean を使用できます。
この節では、セッション 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 固有の機能
制御の対象 | 設定する weblogic-ejb-jar.xml の要素 | デフォルト動作 |
---|---|---|
起動時の WebLogic Server に存在するステートレス セッション Bean の非アクティブなインスタンスの数。 「ステートレス セッション EJB のプール」を参照。 |
|
フリー プールで Bean は作成されない。 |
プール内の Bean がアイドル状態でいることができる秒数。WebLogic Server はその秒数が経過すると Bean を削除できる。 注意 : アイドル状態の Bean は、プール内の Bean 数が |
|
WebLogic Server は、フリー プールの Bean が 600 秒アイドル状態である場合にその Bean を削除する。 |
非アクティブなステートレス セッション Bean のフリー プールの最大サイズ。 |
|
フリー プールの Bean の最大数は 1000 に制限される。 |
クラスタでステートレス セッション EJB のインスタンスがどのようにレプリケートされるのか。 「信頼性と可用性の機能」を参照。 |
|
EJB はクラスタ内の複数のサーバにデプロイできる。 |
表 5-3 ステートフル セッション EJB の WebLogic 固有の機能
動作 | weblogic-ejb-jar.xml の要素 | デフォルト値 |
---|---|---|
|
|
False - ステートフル セッション Bean インスタンスによるメソッド呼び出しの処理中に、同時に他のメソッド呼び出しがサーバに送信されたときに、サーバは |
EJB コンテナがエラーを起こすことなくトランザクション コンテキスト内でステートフル セッション Bean を削除できるかどうか。 |
False - ステートフル セッション Bean がトランザクション コンテキスト内で削除されるとサーバは例外を送出する。 |
|
キャッシュに存在できるステートフル Bean のインスタンスの数。 |
|
1000 |
ステートフル セッション Bean のインスタンスがキャッシュに留まり ( |
|
600 秒 |
キャッシュからステートフル セッション Bean のインスタンスを削除するルール。 |
|
NRU (最近未使用) - この動作の説明については、「怠惰なパッシベーション (NRU)」を参照。 |
パッシベーションされたステートフル セッション Bean のインスタンスの状態を WebLogic Server が格納する場所。 |
|
|
メソッドのフェイルオーバをサポートするには、クラスタ化された EJB の多重呼び出し不変メソッドを指定する。多重呼び出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができる。 |
|
なし |
ホーム メソッド呼び出しのルーティングに使用するカスタム クラス。 |
なし |
|
Bean のホームがクラスタ化できるかどうかを示す。 |
|
True |
Bean ホームのレプリカ間でロード バランシングを行うためのアルゴリズム。 |
|
プロパティ |
クラスタのステートフル セッション Bean に使用するレプリケーションを示す (in-memory または none)。 |
|
なし |