| Sun ONE Application Server 7, Enterprise Edition 管理者ガイド |
第 7 章
J2EE コンテナの設定Sun ONE Application Server 7, Enterprise Edition は、J2EE 1.3 仕様に準拠したさまざまな J2EE コンテナを提供します。コンテナは、EJB (Enterprise Java Beans) や MDB (メッセージ駆動型 Beans) などの J2EE アプリケーションコンポーネントの実行時サポートを提供します。MDB および EJB が、他の J2EE アプリケーションコンポーネントと直接対話することはありません。これらのアプリケーションコンポーネントは、EJB コンテナのプロトコルとメソッドを使って、その他のアプリケーションコンポーネントや、Java トランザクションサービスなどのプラットフォームサービスと対話します。コンテナは、アプリケーションコンポーネントと J2EE サービスの間に介在します。このため、コンテナは、コンポーネントの配備記述子によって定義されたサービス (宣言型トランザクション管理、セキュリティチェック、リソースプーリング、状態管理など) を透過的に組み込むことができます。
Sun ONE Application Server には、Web コンテナおよび EJB コンテナが組み込まれています。
この章では次のトピックについて説明します。
Web コンテナについてWeb コンテナは、Web アプリケーションをホストする J2EE コンテナです。Web コンテナは、サーブレットと JSP (Java Server Pages) の実行時環境を開発者に提供することにより、Web サーバーの機能を拡張します。サーブレットでは、コンポーネントをベースにし、プラットフォームに依存しない方法で Web ベースのアプリケーションを構築できます。CGI (Common Gateway Interface) プログラムのパフォーマンス制限はありません。JSP テクノロジは、サーブレットテクノロジの拡張であり、HTML および XML ページのオーサリング機能を提供します。Web コンテナに含まれるサーブレットや JSP は、EJB (Enterprise Java Beans) コンテナ内の Bean メソッドを呼び出すことができます。Bean メソッドは、ORB (Object Request Broker) によってローカルまたはリモートで呼び出されます。
また、Web コンテナは、JNDI (Java Naming Directory Interface) で検索されたローカル EJB に対して、Web アプリケーションアクセスを提供します。
次の図「アーキテクチャ内の Web コンテナ」では、Sun ONE Application Server 7, Enterprise Edition アーキテクチャにおける Web コンテナの役割と位置付けを示します。
図 7-1 アーキテクチャ内の Web コンテナ
この節には次の項目があります。
Web コンテナの役割
Web コンテナの第 1 の役割は、Web アプリケーションにランタイム環境を提供し、コンテナ内でホストされる Web アプリケーションにサービス (データベースアクセス、セキュリティ、マルチスレッドなど) を提供することです。Web アプリケーションは、Sun ONE Application Server 7, Enterprise Edition 上で完全なアプリケーションを構成するサーブレット、HTML ページ、クラス、およびその他のリソースの集合です。
Web アプリケーションの要素を次に示します。
Web アプリケーションは、Sun ONE Application Server 7, Enterprise Edition で実行中の Web コンテナに配備できます。
Sun ONE Application Server 7, Enterprise Edition での Web サーバープラグインの詳しい設定方法および使用方法については、"Configuring the Web Server Plugin" on page 187を参照してください。
Web アプリケーションの設定
Web コンテナの設定により、仮想サーバー内に Web アプリケーションを配備することもできます。Web コンテナに複数の仮想サーバーを設置する設定も可能です。各仮想サーバーには、任意の数の Web アプリケーションをホストさせることができます。Web アプリケーションの使用範囲は、仮想サーバーのコンテキスト内です。仮想サーバーの詳細は、第 14 章「仮想サーバーの使用」を参照してください。
この節では次の項目について説明します。
仮想サーバー属性
仮想サーバーには、設定可能な一定の属性値を指定できます。仮想サーバーには、複数の Web アプリケーションを関連付けることができます。ユーザーは Web アプリケーションに「サインオン」する必要があります。
server.xml ファイルでシングルサインオンの属性である sso-enabled をデフォルト値 true に設定した場合、ユーザーは特定の仮想サーバーに関連付けられたいずれか 1 つの Web アプリケーションにサインオンできます。この場合、同じ仮想サーバーで実行中のその他すべての Web アプリケーションが、ユーザーの識別情報を認識します。sso-enabled 属性の値を false に設定した場合、この仮想サーバーのすべてのアプリケーションで、シングルサインオンが無効になります。
sso-enabled 属性は動的に設定できます。つまり、サーバーを再起動しなくても設定内容が有効になります。
シングルサインオンの詳細は、「シングルサインオン機能」を参照してください。
Web モジュール属性
Web アプリケーションの WEB-INF ディレクトリにある sun-web.xml ファイルには、Sun ONE Application Server 7, Enterprise Edition 固有の配備記述子が指定されます。
通常、sun-web.xml ファイルは Web アプリケーションごとに 1 つずつ設定されます。ただし、Web コンテナは、sun-web.xml ファイルを Web アプリケーションごとに 1 つずつ設定しなくても動作します。sun-web.xml ファイルが存在しない場合、Web コンテナは、Sun ONE Application Server 7, Enterprise Edition 固有のすべての属性についてデフォルト値を使用します。
context-root 属性
この属性は、Web アプリケーションのインストール先となるコンテキストルートを定義します。属性値として空文字列を指定した場合、この Web アプリケーションが仮想サーバーのデフォルトの Web アプリケーションになります。仮想サーバーのデフォルトの Web アプリケーションは、仮想サーバー上に配備されたその他の Web アプリケーションに解決されない要求すべてに応答します。各仮想サーバーには、デフォルトの Web アプリケーションが 1 つずつ割り当てられます。
デフォルトの Web アプリケーションの場合、このフィールドの値は空文字列 "" にします。
location 属性
この属性には、デフォルトの Web アプリケーションの位置を表す有効なディレクトリパスを指定します。インストール時に、デフォルトの Web アプリケーションの位置は modules/default-web-app/ ディレクトリに設定されます。
location 属性は必須であり、その値は WAR (Web ARchive) ファイルのコンテンツが抽出されるディレクトリの絶対パスまたは相対パスになります。指定されたパスが相対パスの場合、そのパスは、仮想サーバーレベルで定義されたアプリケーションルートディレクトリと関連を持っている必要があります。
次に例を示します。
location="applications/<ear name>/<war-module name>/"
location="modules/<war-module name>"
location="/u/myapps/<war-module name>"
location="/u/myapps/<ear-name>/<war-module name>"
enabled 属性
この属性のデフォルト値は true です。これは、Web アプリケーションがサービス要求に対して有効であることを示します。enabled 属性の値を false にすると、Web アプリケーションをサービス要求に対して一時的に無効にできます。ただし、Web アプリケーションのコンテンツは、ハードディスクに格納されているため、削除されません。
Web アプリケーションの配備
Web コンテナは、WAR (Web ARchive) ファイルまたは WAR ファイルの分割ビュー (WEB-INF/lib クラス、WEB-INF/ クラスなど) を含むディレクトリから Web アプリケーションを配備します。アプリケーションを配備するために、サーバーを再起動する必要はありません。
Web コンテナは、各仮想サーバーに「デフォルト」の Web アプリケーションを配備します。デフォルトの位置 (ディレクトリ) は、仮想サーバーの app root ディレクトリのサブディレクトリ、modules/default-web-app/ です。このデフォルトの Web アプリケーションは、仮想サーバー上に配備されたその他の Web アプリケーションに解決されない要求すべてに応答します。この Web アプリケーションは、/servlet/* への要求を処理する呼び出し元サーブレットと、JSP ページを提供する JSP サーブレットで構成されます。デフォルトの Web アプリケーションから EJB にアクセスするためには、web.xml ファイルおよび sun-web.xml ファイル内の EJB 参照を示す必要があります。
デフォルトの Web アプリケーションは、次のように、仮想サーバーの server.xml に定義されます。
<web-module context-root="" location="modules/default-web-app/">
動的再配備とホット配備機能
動的再配備により、サーバーを再起動することなく既存のアプリケーションを配備し直すことができます。動的再配備は、アプリケーションの設定 (xml ファイルのコンテンツ) や特定のクラスが変更されたときに行われます。動的再配備を行うと、アプリケーションクラス全体の動的再読み込みをした場合と同じ結果になります。さらに、新しいアプリケーションコンテキスト (web および ejb) が作成され、古いアプリケーションコンテキストが削除されます。このように、動的再配備では、まったく新しいアプリケーションインスタンス (既存のセッションデータを除く) が作成されることになります。動的再配備をサポートするには、配備モードにする必要があります。この機能の使用時に発行される例外は、動的再読み込みで発行される例外とほぼ同じです。また、サーバーの再起動が必要になる変更を設定に加えた場合、変更内容を有効にするにはサーバーを再起動する必要があります。動的再読み込み機能は、それを指定する中央の設定ファイルを持つアプリケーションおよび非共有のスタンドアロンモジュールだけで有効です。
Web アプリケーションの再読み込みを行うと、セッションマネージャの持続性の設定とは関係なく、既存のセッション情報がすべて自動的に保存および復元されます。
ホット配備は、サーバーを再起動することなく、サーバーの実行時にアプリケーションを配備する機能です。この機能では、動的再配備と同じインフラストラクチャを使用します。ただし、以前の状態は引き継がれないため、この機能は本番稼働時にサポートされます。
シングルサインオン機能
ユーザーが特定の仮想サーバー上で、任意の Web アプリケーションの保護されていないリソースだけにアクセスする場合、自分自身を認証する必要はありません。
特定の仮想サーバー上で、任意の Web アプリケーションの保護されているリソースにアクセスする場合、ユーザーはアクセス対象の Web アプリケーションに定義されているログインメソッドを使って、自分自身を認証します。
認証が完了すると、関連するすべての Web アプリケーションで、このユーザーに割り当てられたロールによるアクセス制御が行われます。ユーザーは、各 Web アプリケーションで個別に認証を行う必要はありません。
ユーザーが Web アプリケーションからログアウトすると、このユーザーのセッションは、すべての Web アプリケーションで無効になります。それ以降、アプリケーション内の保護されているリソースにアクセスするには、再度ユーザー認証を行う必要があります。
シングルサインオン機能は、HTTP Cookie を使ってトークンを転送し、個々の要求と保存されているユーザーの識別情報を関連付けます。したがって、この機能は、Cookie をサポートするクライアント環境以外ではサポートされません。
Web コンテナのロギング
さまざまなログレベルを設定することにより、Web コンテナのデフォルトのロギング動作と、仮想サーバー内でホストされている任意のアプリケーションのデフォルトのロギング動作を制御できます。このロギング動作は、アプリケーション独自のロギングには影響しません。
ログレベルを指定して、ログに記録するメッセージの種類を制御します。たとえば、ログレベル FATAL のメッセージだけを記録するように指定した場合、このレベルより上のレベルのメッセージは無視されます。明示的に指定されたログレベルで記録されるメッセージだけが、この値と比較されます。
明示的に指定されてないログレベルで記録されたメッセージは、無条件に記録されます。デフォルトでは、すべての警告、エラー、致命的なメッセージが記録されます。
Web コンテナのログレベルを設定するには、次の手順に従ってください。
- 管理インタフェースの左側のペインで、Sun ONE Application Server 7, Enterprise Editionインスタンスツリーを展開して、変更する Web コンテナ設定を探します。
- 表示された J2EE コンテナの一覧から「Web Container (Web コンテナ)」を選択します。管理インタフェースの右側のペインに、Web コンテナのロギングのページが表示されます。
図 7-2 Web コンテナのロギング
- 「Log Level (ログレベル)」ドロップダウンリストからログレベルを選択します。すべてのログレベルとその定義については、第 5 章「ログの使用」を参照してください。
- 「Save (保存)」をクリックして設定を保存します。
Web コンテナの追加のプロパティを作成するには、「Properties (プロパティ)」ボタンをクリックしてください。
EJB コンテナについてEnterprise JavaBean コンテナは、Enterprise JavaBean を制御し、システムレベルの重要なサービスを提供する実行時環境です。EJB は、EJB コンテナ内で実行されるコンポーネントです。これらは、EJB サーバー内で順番に実行されます。Beans には、次のようなシステムレベルのサービスが提供されます。
Enterprise JavaBean は、ビジネスロジックを含む Java で記述されたサーバーコンポーネントです。EJB コンテナは、Bean へのリモートアクセス機能を提供します。EJB は常にコンテナのコンテキスト内で動作します。コンテナは、EJB とそれらを管理するサーバー間のリンクとして機能します。EJB コンテナによって、独自のコンポーネントや他の供給元から提供されたコンポーネントを使った分散アプリケーションを構築できます。
Sun ONE Application Server 7, Enterprise Edition では、EJB コンテナを通して高レベルのトランザクション、状態管理、マルチスレッド、およびリソースプールラッパーを提供するので、管理者が低レベル API の詳細を理解する必要はありません。このコンテナは、EJB 2.0 仕様に規定されているすべての標準コンテナサービスに加えて、Sun ONE Application Server 7, Enterprise Edition に固有のサービスも提供します。
コンテナは、非活性化および活性化プロセスを使って、Bean のアクティビティを管理し、スケーラビリティを確保します。
この節には次の項目があります。
EJB コンテナの役割
EJB コンテナは、次の標準サービスを提供します。
Sun ONE Application Server サービスには、リモートアクセス、ネーミング、セキュリティ、並行処理、トランザクション制御、データベースアクセスなどがあります。
EJB コンテナの機能は次のとおりです。
実際の実装の詳細は、コンテナとその EJB 間の指定された標準インタフェースに基づいて、コンテナの一部となります。プラットフォーム固有の実装の詳細を把握したり、それを直接扱ったりする必要はありません。その代わりに、EJB 標準をサポートする任意のベンダーの製品とともに使用できる、一般的なタスク限定の EJB を作成できます。
Sun ONE Application Server 7, Enterprise Edition で使用される EJB の種類を理解しておくことをお勧めします。
Enterprise JavaBeans の種類
EJB は、次のいずれかを表すオブジェクトです。特定のクライアントとのセッション。
エンティティ Beans は、主に、JDBC (Java Database Connectivity) API を使ったデータアクセス処理に使用されます。一方、セッション Beans は、一時的なアプリケーションオブジェクトを提供し、個々のビジネスタスクを実行します。EJB は 3 種類あります。次の各項目で説明します。
セッション Beans について
セッション Bean は、ビジネス規則または特定のクライアント要求のロジックを実装します。
セッション Beans は、一時的なオブジェクトおよびプロセス (単一のデータベースレコードの更新、これから編集する文書コピー、個々のクライアントに固有のビジネスオブジェクトなど) を表します。つまり、セッション Beans は、そのセッション Beans を作成するクライアントだけが使用するプライベートリソースです。これらのオブジェクトは単一のクライアントだけが使用できるため、セッション Beans は会話型ステートと呼ばれるクライアント固有のセッション情報を維持できます。
たとえば、EJB を作成して電子ショッピングカートをシミュレートするとします。ユーザーがアプリケーションにログインするたびに、アプリケーションはショッピングカートのセッション Bean を作成して、そのユーザーが購入したアイテムを保持します。ユーザーがログアウトするか、ショッピングを終了すると、セッション Bean は解放されます。
セッション Beans には次の特性があります。
ステートレスのセッション Beans。ステートレスのセッション Beans は、限られた時間内で、特定のクライアントに必要なビジネスロジックの一時的な部分をカプセル化します。ステートレスのセッション Beans は、会話型ステートを維持しません。
ステートフルのセッション Beans。ステートフルのセッション Beans も一時的ですが、会話型ステートを使って、次のクライアント呼び出しまでコンテンツおよび値に関する情報を保持します。会話型ステートにより、Beans のコンテナはセッション Beans の状態情報を保持し、プログラム実行中に必要に応じてその状態を再現できます。
エンティティ Beans について
一般に、エンティティ Beans は、データベース内で直接保持される持続データ、または EIS (Enterprise Information System) アプリケーションを介してオブジェクトとしてアクセスされる持続データを表します。EJB および EJB コンテナをホストするサーバーは、同時にアクティブになっているエンティティ EJB にスケーラブルな実行時環境を提供します。
簡単なエンティティ Bean の例としては、データベーステーブルの 1 行を表すように定義され、各 Bean インスタンスが特定の行を表すものがあります。より複雑な例としては、データベース内の結合されたテーブルの複雑なビューを表すように設計されたものがあります。たとえば、各 Bean インスタンスが 1 つのショッピングカートの内容を表すエンティティ Bean などです。
エンティティ Beans には次の特性があります。
エンティティ Beans は、持続データをコンテナ管理または Bean 管理の持続性として表します。エンティティ Beans の持続性は、Bean またはコンテナによって管理できます。
Bean 管理の持続性。エンティティ Bean が独自の持続性を管理します。Bean 開発者が EJB クラスメソッドに持続コード (JDBC 呼び出しなど) を直接実装します。専用インタフェースを使うと、ダウンサイドでは移植性が失われる可能性があり、Bean が特定のデータベースに関連付けられるというリスクがあります。
コンテナ管理の持続性。エンティティ Bean の持続性がコンテナによって管理されます。コンテナは持続的状態を透過的に管理するので、Bean メソッドにデータアクセスコードを実装する必要はありません。この方法によって、簡単に実装できるだけでなく、特定のデータベースに関連付けずに完全に Bean を移植できます。
コンテナ管理の持続性を使用するエンティティ Bean は、Bean 管理の持続性を使用するエンティティ Bean のうち、コンテナによって自動生成されるものです。
エンティティ Beans の構築と使用に関する詳細は、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』を参照してください。
メッセージ駆動型 Beans について
メッセージ駆動型 Beans は、J2EE アプリケーションでメッセージを非同期的に処理できる EJB です。メッセージ駆動型 Beans は、Java Message Service メッセージの着信によって動作します。
メッセージ駆動型 Bean インスタンスは、作成されてから削除されるまで、メッセージ駆動型 Bean コンテナ内にあります。コンテナは、メッセージ駆動型 Bean インスタンスのセキュリティ、トランザクション、メッセージの並行処理、ライフサイクル管理など、メッセージ駆動型 Bean に関するさまざまなサービスを提供します。EJB および EJB コンテナを管理するサーバーは、同時にアクティブになっているメッセージ駆動型 Beans にスケーラブルな実行時環境を提供します。
J2EE 1.3 プラットフォームの Java Message Service API には、次のことが指定されています。
メッセージ駆動型 Bean はステートレスのサービスを表します。これは、完全に匿名で、クライアントに識別情報を公開しない非同期メッセージコンシューマです。メッセージ駆動型 Bean は、ホームインタフェースもコンポーネントインタフェースも持ちません。クライアントは、メッセージ駆動型 Bean クラスが MessageListener である Java Message Service の送信先 (キューまたはトピック) にメッセージを送信することにより、Java Message Service を介してメッセージ駆動型 Beans にアクセスします。
メッセージ駆動型 Beans のみが、非同期でメッセージを受け取ることができます。セッション Beans やエンティティ Beans は、Java Message Service の MessageListener にはなれません。
メッセージ駆動型 Beans には次の特性があります。
EJB コンテナの設定
EJB コンテナのログレベルを設定できます。また、監視を有効にすることも可能です。EJB コンテナは、EJB と MDB の両方を処理します。コンテナが管理する EJB と MDB については、管理インタフェースを使って設定できます。この節には次の項目があります。
一般設定
EJB コンテナに関して次の項目を設定します。
EJB コンテナのログレベルの設定、監視の有効化、およびトランザクション属性の設定を行うには、次の手順に従います。
- 管理インタフェースの左側のペインで、Sun ONE Application Server 7, Enterprise Edition インスタンスツリーを展開して、変更する EJB コンテナ設定を探します。
- コンテナのリストを表示し、ここから「EJB Container (EJB コンテナ)」を選択します。管理インタフェースの右側のペインに、次のような EJB コンテナの一般設定用のウィンドウが表示されます。
図 7-3 EJB コンテナの一般設定
- 「Monitoring Enabled (監視を有効)」のチェックボックスにチェックマークをつけて、EJB コンテナの監視を有効にします。これで、指定したSun ONE Application Server 7, Enterprise Editionインスタンスの EJB コンテナの監視が有効になりました。EJB コンテナの監視可能な項目については、「EJB コンテナ統計情報の監視」の表を参照してください。
- 「Log Level (ログレベル)」ドロップダウンリストからログレベルを選択します。すべてのログレベルとその定義については、第 5 章「ログの使用」を参照してください。ログレベルを指定して、ログに記録するメッセージの種類を制御します。たとえば、ログレベル FATAL のメッセージだけを記録するように指定した場合、このレベルより上のレベルのメッセージは無視されます。明示的に指定されたログレベルで記録されるメッセージだけが、この値と比較されます。
明示的に指定されてないログレベルで記録されたメッセージは、無条件に記録されます。デフォルトでは、すべての警告、エラー、致命的なメッセージが記録されます。
- 「Commit Option (コミットのオプション)」ドロップダウンリストで、EJB コンテナに使用する「Commit Option (コミットのオプション)」を選択します。
トランザクションの終了方法には、コミットまたはロールバックによる 2 種類があります。トランザクションがコミットすると、ステートメントによって変更されたデータは保存されます。Enterprise JavaBean の設計時には、コミットがコンテナ管理のトランザクションと Bean 管理のトランザクションのどちらであるかを決めます。ドロップダウンリストの選択肢では、「B」は Bean 管理のコミットを、「C」はコンテナ管理のコミットを示しています。
- 「Properties (プロパティ)」ボタンをクリックして、EJB コンテナの新しいプロパティを作成します。
- 「OK (了解)」をクリックして、設定を保存します。
監視可能な EJB コンテナの属性を次の表に示します。
EJB 設定
管理インタフェースを使うと、EJB コンテナに管理される EJB のデフォルトのプールと Bean キャッシュに関する設定を行うことができます。次の各項目で説明します。
EJB プールを設定するには
EJB プール設定を行うには、次の手順に従います。
- 管理インタフェースの左側のペインで、EJB 設定を変更する Sun ONE Application Server 7, Enterprise Edition インスタンスツリーを展開します。
- コンテナのリストを表示し、ここから「EJB Container (EJB コンテナ)」を選択します。管理インタフェースの右側のペインに、次のような EJB プールの設定用のウィンドウが表示されます。
図 7-4 EJB プールの設定
- 「Steady Pool Size (通常プールサイズ)」フィールドに、プール内の Beans の最小数を指定します。これは、ステートレスのセッション Beans に適用されます。
- 「Max Pool Size (最大プールサイズ)」ドロップダウンリストに、任意の時点でプール内に格納できる Beans の最大数を指定します。この設定は、ステートレスのセッション Beans に適用されます。
- 「Pool Resize Quantity (プールサイズ変更量)」フィールドに、Beans が idle-timeout-in-seconds タグで指定された時間を超えてアイドル状態であった場合にプールから削除される Beans 数を指定します。
- 「Idle Timeout (secs) (アイドルタイムアウト (秒))」フィールドに、Bean がアイドル状態で残ることができる期間を秒単位で指定します。アイドルタイムアウトの期間が経過してもアイドル状態のままである Bean は削除されます。
- 「Save (保存)」をクリックして変更を保存します。
EJB キャッシュを設定するには
EJB キャッシュ設定を行うには、次の手順に従います。
- 管理インタフェースの左側のペインで、EJB 設定を変更する Sun ONE Application Server 7, Enterprise Edition インスタンスツリーを展開します。
- コンテナのリストを表示し、ここから「EJB Container (EJB コンテナ)」を選択します。管理インタフェースの右側のペインに、次のような EJB プールの設定用のウィンドウが表示されます。
図 7-5 EJB キャッシュの設定
- 「Max Cache Size (最大キャッシュサイズ)」フィールドに、キャッシュに保持される Beans の最大数を指定します。この属性のデフォルト値は、idle-timeout-in-seconds 属性に指定されています。
- 「Cache Resize Quantity (キャッシュサイズ変更量)」フィールドに、プール内の Beans 数が Max Cache Size 属性に指定された量を超えた場合に削除する Beans 数を指定します。
- 「Removal Timeout (secs) (削除タイムアウト (秒))」フィールドに、バックアップストア内でアイドル状態の Bean が非活性化されたままでいられる時間を指定します。Bean がクライアントからアクセスされない期間が removal-timeout-in-seconds 属性に指定された値を経過すると、Bean はバックアップストアから削除されるため、それ以降クライアントはアクセスできなくなります。
- 「Victim Selection Policy (犠牲の選択の方針)」ドロップダウンリストで、プールからの削除時に犠牲 (削除対象) となる Beans を選択するためのアルゴリズムを指定します。
- 「Idle Timeout (secs) (アイドルタイムアウト (秒))」フィールドに、Bean がキャッシュ内でアイドル状態でいられる期間を指定します。この期間を過ぎると Bean は削除されます。Bean をアイドルバックアップストアに非活性化の状態で残す期間は、removal-timeout-in-seconds パラメータによって制御されます。
- 「Save (保存)」をクリックして変更を保存します。
MDB プールの設定
管理インタフェースを使うと、EJB コンテナが管理する MDB のデフォルトのプール設定を行うことができます。MDB のデフォルトのプール設定を行うには、次の手順に従います。
- 管理インタフェースの左側のペインで、変更する MDB コンテナ設定を含む Sun ONE Application Server 7, Enterprise Edition インスタンスツリーを開きます。
- コンテナのリストを表示し、ここから「EJB Container (EJB コンテナ)」を選択します。管理インタフェースの右側のペインに、次のような MDB プールの設定用のウィンドウが表示されます。
図 7-6 MDB プールの設定
- 「MDB Settings (MDB 設定)」をクリックします。「Steady Pool Size (通常プールサイズ)」テキストフィールドに、プール内の Beans の最小数を指定します。これは、ステートレスのセッション Beans に適用されます。
- 「Max Pool Size (最大プールサイズ)」フィールドに、任意の時点でプール内に格納できる Beans の最大数を指定します。
- 「Pool Resize Quantity (プールサイズ変更量)」フィールドに、Beans が idle-timeout-in-seconds タグで指定された時間を超えてアイドル状態であった場合にプールから削除される Beans 数を指定します。
- 「Idle Timeout (secs) (アイドルタイムアウト (秒))」フィールドに、Bean がアイドル状態で残ることができる期間を秒単位で指定します。アイドルタイムアウトの期間が経過してもアイドル状態のままである Bean は削除されます。
- 「Save (保存)」をクリックして設定を保存します。
