5 セッションEJB

この項では、セッションBeanがEJBコンテナの中でどのように機能するのかを説明し、セッションBeanに固有の設計および開発ガイドラインも提供します。Bean開発の全体的なプロセスについては、「Enterprise JavaBeansの実装」を参照してください。

この章は、JavaのプログラミングおよびセッションBeanの機能に精通している読者を対象としています。セッションBeanの機能の概要およびセッションBeanのアプリケーションでの典型的な使用方法については、「セッションEJBによるビジネス・ロジックの実装」および「セッションBeanの機能」を参照してください。

以下の節では、セッションBeanのライフサイクル、設計上の考慮事項、および主要な実装タスクの手順について説明します。

• ステートレス・セッションBeanとステートフル・セッションBeanの比較

• ステートレス・セッションEJBのプール

• ステートフル・セッションEJBのキャッシュとパッシブ化

• セッションBeanの設計上の決定

• セッションBeanの実装

ステートレス・セッションBeanとステートフル・セッションBeanの比較

この節では、ステートレス・セッションBeanとステートフル・セッションBeanの主な違いについて説明します。

表5-1 ステートレス・セッションBeanとステートフル・セッションBeanの比較

ステートレス・セッションBean	ステートフル・セッションBean
必要になるたびにBeanを作成するオーバーヘッドを削減するためにメモリーにプールされます。WebLogic Serverは必要なときにBeanのインスタンスを使用し、処理が完了したらそれをプールに戻します。 ステートレス・セッションBeanは、ステートフルBeanよりも処理速度が高速です。	各クライアントはBeanの新しいインスタンスを作成し、最終的にそれを削除します。インスタンスは、キャッシュがいっぱいの場合はディスクにパッシブ化できます。 アプリケーションはejbRemove()を発行してBeanをキャッシュから削除します。 ステートフル・セッションBeanは、ステートレス・セッションBeanほどのパフォーマンスは発揮しません。
IDがなく、クライアントとの関連付けもありません。匿名です。	特定のクライアント・インスタンスにバインドされます。各Beanには暗黙のIDがあります。クライアントがセッション中にステートフル・セッションBeanと対話する場合、それは毎回同じオブジェクトに対して行われます。
持続しません。Beanに呼出し間の状態はありません。	持続します。ステートフル・セッションBeanの状態は、セッションが終わるまで保持されます。

どのタイプのセッションBeanをいつ使用するのかについては、「ステートレスBeanとステートフルBeanの選択」を参照してください。

ステートレス・セッションEJBのプール

デフォルトでは、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プールを必要に応じて初期化できます。EJBのプールを初期化すると、そのプールはEJBのデプロイ直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態のBeanのキャッシュとプールの初期化に関する項を参照してください。

次の図に、WebLogic Serverのフリー・プールと、ステートレスEJBがフリー・プールに出入りするプロセスを示します。点線は、WebLogic Server側から見たEJBの「状態」を表しています。

図5-1 ステートレス・セッションEJBのライフサイクルを示すWebLogic Serverフリー・プール

「図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インスタンスが使用可能になるまで待機する必要があります。

ステートフル・セッションEJBのキャッシュとパッシブ化

WebLogic Serverは、Beanインスタンスのキャッシュを使用してステートフル・セッションEJBのパフォーマンスを高めます。キャッシュはメモリー内にアクティブなEJBインスタンスを格納することで、それらをクライアント・リクエストに即座に使用できるようにしています。キャッシュには、クライアントによって現在使用されているEJBと最近使われていたインスタンスが格納されます。キャッシュ内のステートフル・セッションBeanは、特定のクライアントと結び付いています。

次の図に、WebLogic Serverのキャッシュと、ステートフルEJBがキャッシュに出入りするプロセスを示します。

図5-2 ステートフル・セッションEJBのライフサイクル

「図5-2 ステートフル・セッションEJBのライフサイクル」の説明

ステートフル・セッションEJBの作成

WebLogic Serverには起動時にステートフル・セッションEJBインスタンスは存在しません。クライアントがステートフル・セッションBeanへのアクセスを開始する前に、Beanとのセッションで使用する新しいBeanインスタンスが作成されます。セッションが終了すると、インスタンスは破棄されます。セッションが進行中の間は、インスタンスはメモリーにキャッシュされます。

ステートフル・セッションEJBのパッシブ化

パッシブ化は、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の値に基づいてパッシブ化と削除の動作に影響を与えます。

即時パッシブ化(LRU)

cache-typeをLRUに設定してステートフル・セッションBeanの即時パッシブ化を構成すると、コンテナは以下のようにしてインスタンスをディスクにパッシブ化します。

• max-beans-in-cacheの値に関係なく、インスタンスの非アクティブな状態がidle-timeout-secondsの期間を経過するとすぐ

• idle-timeout-secondsが経過していなくても、max-beans-in-cacheに達したとき

コンテナは、パッシブ化されたインスタンスを、そのパッシブ化後、idle-timeout-secondsの期間非アクティブな状態が続いた後にディスクから削除します。この動作は、遅延削除と呼ばれます。

注意: idle-timeout-secondsに達すると削除されるBeanインスタンスでejbRemoveを呼び出すことはできません。

遅延パッシブ化(NRU)

cache-typeをNRUに設定して遅延パッシブ化を構成すると、関連するシステムのオーバーヘッドが原因でコンテナはBeanのパッシブ化を回避します(キャッシュに影響を与えるのは、Beanのパッシブ化または即時削除を引き起こすイベントのみとなります)。

キャッシュがいっぱいになり、Beanインスタンスをキャッシュから削除して別のインスタンス用のスペースを確保する場合、コンテナは次のようになります:

注意: idle-timeout-secondsに達すると削除されるBeanインスタンスでejbRemoveを呼び出すことはできません。

• idle-timeout-secondsが経過したときにキャッシュからBeanのインスタンスを削除し、それをディスクにパッシブ化することはしません。この動作は、即時削除と呼ばれます。即時削除を行うと、アクティブでないインスタンスによってメモリーまたはディスクのリソースが消費されなくなります。

• idle-timeout-secondsの有効期限が切れない場合、Beanのインスタンスをディスクにパッシブ化します。

パッシブ化されたBeanの永続ストア・ディレクトリの指定

ステートフル・セッションBeanがパッシブ化されると、その状態がファイル・システムのディレクトリに格納されます。各サーバー・インスタンスには、パッシブ化されたステートフル・セッションbeanの状態を格納する専用のディレクトリ永続ストア・ディレクトリがあります。永続ストア・ディレクトリは、パッシブ化されたBeanごとに1つのサブディレクトリを格納します。

永続ストア・ディレクトリは、たとえば次のようにサーバー・インスタンスのディレクトリにデフォルトで作成されます。

D:\releases\<version>\bea\user_domains\mydomain\myserver\tmp\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

ステートフル・セッションBeanへの同時アクセスの構成

EJB 2.x仕様に従って、ステートフル・セッションEJBに同時アクセスするとRemoteExceptionがスローされます。ステートフル・セッションEJBに関するこのアクセス制限は、EJBクライアントがWebLogic Serverの内部にあるのかそれともリモートにあるのかに関係なく適用されます。この制限を無効にして、同時呼出しが可能なようにステートフル・セッションBeanを構成するには、allow-concurrent-callsデプロイメント要素を設定します。

複数のサーブレット・クラスがステートフル・セッションEJBにアクセスする場合は、サーブレット・クラスのインスタンスごとではなくサーブレット・スレッドごとに独自のセッションEJBインスタンスを使用する必要があります。同時アクセスを避けるために、JSPまたはサーブレットはリクエスト・スコープでステートフル・セッションBeanを使用できます。

セッションBeanの設計上の決定

この節では、セッションBeanに関連するいくつかの設計上の決定について説明します。

ステートレスBeanとステートフルBeanの選択

ステートレス・セッションBeanは、アプリケーションでビジネス・メソッドの呼出しの間に特定クライアントの状態を保持する必要がない場合は適切な選択肢です。WebLogic Serverはマルチスレッドで、複数のクライアントに同時にサービスを提供します。ステートレス・セッションBeanを使用した場合、EJBコンテナはセッションの間各クライアントのインスタンスを確保するのではなく、プールにある利用可能なBeanインスタンスを自由に利用してクライアント・リクエストに応えることができます。その結果、リソースの使用率、スケーラビリティ、およびスループットが向上します。

ステートレス・セッション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はサーバー・インスタンスのワーカー・スレッドと同数にします。そうすれば、スレッドが処理を試みるときに、インスタンスが利用可能な状態にあります。

セッションBeanの実装

第4章では、セッションBean実装の手順が説明されています。この節では、Bean固有のデプロイメント記述子要素を設定してWebLogic Server固有のセッションBeanの動作を構成する詳細について説明します。

WebLogicに固有のセッション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のプール」を参照してください。	initial-beans-in-free-pool	フリー・プールでBeanは作成されません。
プール内のBeanがアイドル状態でいることができる秒数。WebLogic Serverはその秒数が経過するとBeanを削除できます。 注意: アイドル状態のBeanは、プール内のBean数がinitial-beans-in-free-poolに達するまで削除されます。	idle-timeout-seconds	WebLogic Serverは、フリー・プールのBeanが600秒アイドル状態である場合にそのBeanを削除します。
非アクティブなステートレス・セッションBeanのフリー・プールの最大サイズ。	max-beans-in-free-pool	フリー・プールのBeanの最大数は1000に制限されます。
クラスタでステートレス・セッションEJBのインスタンスがどのようにレプリケートされるのか。 「信頼性と可用性の機能」を参照してください。	stateless-clustering home-is-clusterable home-load-algorithm home-call-router-class-name stateless-bean-is-clusterable stateless-bean-load-algorithm stateless-bean-call-router-class-name stateless-bean-methods-are-idempotent	EJBはクラスタ内の複数のサーバーにデプロイできます。

表5-3 ステートフル・セッションEJBのWebLogic固有の機能

動作	weblogic-ejb-jar.xmlの要素	デフォルト値
Remote Exceptionがスローされることなく、複数のクライアントがBeanに同時にアクセスできるかどうか。 「ステートフル・セッションBeanへの同時アクセスの構成」を参照してください。	allow-concurrent-calls	False - ステートフル・セッションBeanインスタンスによるメソッド呼出しの処理中に、同時に他のメソッド呼出しがサーバーに送信されたときに、サーバーはRemoteExceptionをスローします。
EJBコンテナがエラーを起こすことなくトランザクション・コンテキスト内でステートフル・セッションBeanを削除できるかどうか。	allow-remove-during-transaction	False - ステートフル・セッションBeanがトランザクション・コンテキスト内で削除されるとサーバーは例外をスローします。
キャッシュに存在できるステートフルBeanのインスタンスの数。	max-beans-in-cache	1000
ステートフル・セッションBeanのインスタンスがキャッシュに留まり(max-beans-in-cacheに達していないものと仮定)、パッシブ化の後、ディスクに留まるようになるまでの活動のない状態の期間。	idle-timeout-seconds	600秒
キャッシュからステートフル・セッションBeanのインスタンスを削除するルール。	cache-type	NRU (最近未使用) - この動作の説明については、「遅延パッシブ化(NRU)」を参照してください。
パッシブ化されたステートフル・セッションBeanのインスタンスの状態をWebLogic Serverが格納する場所。	persistent-store-dir	pstore
メソッドのフェイルオーバーをサポートするには、クラスタ化EJBの多重呼出し不変メソッドを指定します。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。	idempotent-methods	なし
ホーム・メソッド呼出しのルーティングに使用するカスタム・クラス。	home-call-router-class-name	なし
Beanのホームがクラスタリングできるかどうかを示します。	home-is-clusterable	True
Beanホームのレプリカ間でロード・バランシングを行うためのアルゴリズム。	home-load-algorithm	プロパティweblogic.cluster.defaultLoadAlgorithmで指定されたアルゴリズム。
クラスタのステートフル・セッションBeanに使用するレプリケーションを示します(in-memoryまたはnone)。	replication-type	なし