前へ 目次 索引 次へ
Sun ONE Application Server 7 管理者ガイド

> ## 第 8 章
> J2EE コンテナの設定

> Sun ONE Application Server は、J2EE 1.3 仕様に準拠したさまざまな J2EE コンテナを提供します。コンテナは、EJB (Enterprise Java Beans) や MDB (メッセージ駆動型 Beans) などの J2EE アプリケーションコンポーネントの実行時サポートを提供します。MDB および EJB が、他の J2EE アプリケーションコンポーネントと直接対話することはありません。これらのアプリケーションコンポーネントは、EJB コンテナのプロトコルとメソッドを使って、その他のアプリケーションコンポーネントや、Java トランザクションサービスなどのプラットフォームサービスと対話します。コンテナは、アプリケーションコンポーネントと J2EE サービスの間に介在します。このため、コンテナは、コンポーネントの配備記述子によって定義されたサービス (宣言型トランザクション管理、セキュリティチェック、リソースプーリング、状態管理など) を透過的に組み込むことができます。

> Sun ONE Application Server には、Web コンテナおよび EJB コンテナが組み込まれています。

> この章では次のトピックについて説明します。

> - 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 アーキテクチャにおける Web コンテナの役割と位置付けを示します。

> 図 8-1 アーキテクチャ内の Web コンテナ

> この節には次の項目があります。

> - Web コンテナの役割
> - Web アプリケーションの設定
> - Web アプリケーションの配備
> - シングルサインオン機能
> - Web コンテナのロギング

> ### Web コンテナの役割

> Web コンテナの第 1 の役割は、Web アプリケーションにランタイム環境を提供し、コンテナ内でホストされる Web アプリケーションにサービス (データベースアクセス、セキュリティ、マルチスレッドなど) を提供することです。Web アプリケーションは、Sun ONE Application Server 上で完全なアプリケーションを構成するサーブレット、HTML ページ、クラス、およびその他のリソースの集合です。

> Web アプリケーションの要素を次に示します。

> - サーブレット
> - JSP ページ
> - ユーティリティクラス
> - 静的ドキュメント (HTML、イメージ、音声ファイルなど)
> - クライアントサイドの Java アプレット、Beans、およびクラス
> - 上記のすべての要素を 1 つにまとめる記述的なメタ情報

> Web アプリケーションは、Sun ONE Application Server で実行中の Web コンテナに配備できます。

> Sun ONE Application Server での Web サーバープラグインの詳しい設定方法および使用方法については、第 7 章「Web サーバープラグインの設定」を参照してください。

> ### Web アプリケーションの設定

> Web コンテナの設定により、仮想サーバー内に Web アプリケーションを配備することもできます。Web コンテナに複数の仮想サーバーを設置する設定も可能です。各仮想サーバーには、任意の数の Web アプリケーションをホストさせることができます。Web アプリケーションの使用範囲は、仮想サーバーのコンテキスト内です。仮想サーバーの詳細については、第 15 章「仮想サーバーの使用」を参照してください。

> この節では次の項目について説明します。

> - 仮想サーバー属性
> - Web モジュール属性

> #### 仮想サーバー属性

> 仮想サーバーには、設定可能な一定の属性値を指定できます。仮想サーバーには、複数の 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 固有の配備記述子が指定されます。

> 通常、sun-web.xml ファイルは Web アプリケーションごとに 1 つずつ設定されます。ただし、Web コンテナは、sun-web.xml ファイルを Web アプリケーションごとに 1 つずつ設定しなくても動作します。sun-web.xml ファイルが存在しない場合、Web コンテナは、Sun ONE Application Server 固有のすべての属性についてデフォルト値を使用します。

> ##### 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 コンテナのログレベルを設定するには、次の手順に従ってください。

> 1. 管理インタフェースの左側のペインで、Sun ONE Application Serverインスタンスツリーを展開して、変更する Web コンテナ設定を探します。
> 2. 表示された J2EE コンテナの一覧から「Web コンテナ」を選択します。管理インタフェースの右側のペインに、Web コンテナのロギングのページが表示されます。

> 図 8-2 Web コンテナのロギング

> 1. 「ログレベル」ドロップダウンリストからログレベルを選択します。すべてのログレベルとその定義については、第 5 章「ログの使用」を参照してください。
> 2. 「保存」をクリックして設定を保存します。

> Web コンテナの追加のプロパティを作成するには、「プロパティ」ボタンをクリックしてください。

> ##

> EJB コンテナについて

> Enterprise JavaBean コンテナは、Enterprise JavaBean を制御し、システムレベルの重要なサービスを提供する実行時環境です。EJB は、EJB コンテナ内で実行されるコンポーネントです。これらは、EJB サーバー内で順番に実行されます。Beans には、次のようなシステムレベルのサービスが提供されます。

> - トランザクション管理
> - セキュリティ
> - ライフサイクル管理
> - リモート接続
> - データベースコネクションプーリング
> - ネーミングサービス

> Enterprise JavaBean は、ビジネスロジックを含む Java で記述されたサーバーコンポーネントです。EJB コンテナは、Bean へのリモートアクセス機能を提供します。EJB は常にコンテナのコンテキスト内で動作します。コンテナは、EJB とそれらを管理するサーバー間のリンクとして機能します。EJB コンテナによって、独自のコンポーネントや他の供給元に提供されたコンポーネントを使った分散アプリケーションを構築できます。

> Sun ONE Application Server では、EJB コンテナを通して高レベルのトランザクション、状態管理、マルチスレッド、およびリソースプールラッパーを提供するので、管理者が低レベル API の詳細を理解する必要はありません。このコンテナは、EJB 2.0 仕様に規定されているすべての標準コンテナサービスに加えて、Sun ONE Application Server に固有のサービスも提供します。

> コンテナは、非活性化および活性化プロセスを使って、Bean のアクティビティを管理し、スケーラビリティを確保します。

> この節には次の項目があります。

> - EJB コンテナの役割
> - EJB コンテナの設定

> ### EJB コンテナの役割

> EJB コンテナは、次の標準サービスを提供します。

> - 非活性化

> メモリから二次ストレージへ EJB を転送するプロセス。非活性化では、Bean を削除することなく Bean のリソースを解放できます。これによって、Bean は持続的になり、インスタンス化せずに再び呼び出すことができる。

> - 活性化

> EJB を二次ストレージからメモリに転送するプロセス。コンテナ規約は EJB とそのコンテナ間の関係を規定しており、クライアントに対して完全に透過的です。この関係を次に示します。

> - ライフサイクル

> セッション Beans の場合は、javax.ejb.SessionBean インタフェースおよび javax.ejb.SessionSynchronization インタフェースが実装されています。エンティティ Beans の場合は、javax.ejb.EntityBean インタフェースが実装されています。メッセージ駆動型 Beans の場合は、javax.ejb.MessageDriven インタフェースが実装されています。

> - セッションコンテキスト

> コンテナは javax.ejb.SessionContext インタフェースを実装して、Bean インスタンス作成時にセッション Bean インスタンスにサービスおよび情報を渡します。

> - エンティティコンテキスト

> コンテナは javax.ejb.EntityContext インタフェースを実装して、Bean インスタンス作成時にエンティティ Bean にサービスおよび情報を渡します。

> - メッセージコンテキスト

> コンテナは javax.ejb.MDBContext インタフェースを実装して、Bean インスタンス作成時にメッセージ駆動型 Bean にサービスおよび情報を渡します。

> - 環境

> コンテナは java.util.Properties を実装し、これらのプロパティをそのコンテナの EJB で利用できるようにします。

> - サービス情報

> コンテナは、そのサービスを EJB で利用できるようにします。

> Sun ONE Application Server サービスには、リモートアクセス、ネーミング、セキュリティ、並行処理、トランザクション制御、データベースアクセスなどがあります。

> EJB コンテナの機能は次のとおりです。

> - リモート接続を許可する実装オブジェクト (EJBObject) を作成する
> - EJBObject の作成を許可するホーム実装オブジェクトを作成する
> - クライアントがホームオブジェクトを検索できるように、ホーム実装オブジェクトをネーミングサービスにバインドする
> - 認証されたクライアントのみが Bean メソッドを (EJBObject を介して) 呼び出すことができるようにする
> - ビジネスメソッドが適切なトランザクションから呼び出されるようにする
> - Beans のライフサイクルを管理する。次の方法で Beans のライフサイクルを管理する
> - Beans をプールする
> - 適切なコールバックメソッド (ejbActivate/ejbPassivate など) を呼び出す
> - アプリケーションによる接続の利用または再利用の効率化を図るため、データベース接続プールを管理する

> 実際の実装の詳細は、コンテナとその EJB 間の指定された標準インタフェースに基づいて、コンテナの一部となります。プラットフォーム固有の実装の詳細を把握したり、それを直接扱ったりする必要はありません。その代わりに、EJB 標準をサポートする任意のベンダーの製品とともに使用できる、一般的なタスク限定の EJB を作成できます。

> Sun ONE Application Server で使用される EJB の型を理解しておくことをお勧めします。

> #### Enterprise JavaBeans の種類

> EJB は、次のいずれかを表すオブジェクトです。特定のクライアントとのセッション。

> - クライアントによって起動された複数のメソッドの状態を自動的に管理する
> - 持続的なエンティティオブジェクト。複数のクライアントによって共有可能
> - ステートレスサービス。メッセージ処理など

> エンティティ Beans は、おもに、JDBC (Java Database Connectivity) API を使ったデータアクセス処理に使用されます。一方、セッション Beans は、一時的なアプリケーションオブジェクトを提供し、個々のビジネスタスクを実行します。EJB は 3 種類あります。次の各項目で説明します。

> - セッション Beans について
> - エンティティ Beans について
> - メッセージ駆動型 Beans について

> ##### セッション Beans について

> セッション Bean は、ビジネス規則または特定のクライアント要求のロジックを実装します。

> セッション Beans は、一時的なオブジェクトおよびプロセス (単一のデータベースレコードの更新、これから編集する文書コピー、個々のクライアントに固有のビジネスオブジェクトなど) を表します。つまり、セッション Beans は、そのセッション Beans を作成するクライアントだけが使用するプライベートリソースです。これらのオブジェクトは単一のクライアントだけが使用できるため、セッション Beans は会話型ステートと呼ばれるクライアント固有のセッション情報を維持できます。

> たとえば、EJB を作成して電子ショッピングカートをシミュレートするとします。ユーザーがアプリケーションにログインするたびに、アプリケーションはショッピングカートのセッション Bean を作成して、そのユーザーが購入したアイテムを保持します。ユーザーがログアウトするか、ショッピングを終了すると、セッション Bean は解放されます。

> セッション Beans には次の特性があります。

> - セッション Beans は単一のクライアントとの関連で実行される
> - セッション Beans は比較的短命である
> - セッション Beans ではサーバークラッシュに対する耐久性は保証されない
> - セッション Beans は EJB コンテナのクラッシュ時には削除される
> - セッション Beans はプロパティの設定値に従ってトランザクション管理を行う (オプション)
> - セッション Beans は基になるデータベースで共有データを更新する (オプション)
> - セッション 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 は EIS リソース (通常はデータベース) 内のデータのオブジェクトビューを提供する
> - エンティティ Beans にはすべてのユーザーがアクセス可能である
> - エンティティ Beans はサーバークラッシュ後も透過的に存続する
> - エンティティ Beans はコンテナ管理または 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 には、次のことが指定されています。

> - アプリケーションクライアント、EJB コンポーネント、Web コンポーネントは、Java Message Service メッセージを送信または同期受信できる。さらに、アプリケーションクライアントは、Java Message Service メッセージを非同期で使用できる
> - メッセージ駆動型 Beans は、メッセージの非同期の消費を可能にする。Java Message Service プロバイダは、オプションで、メッセージ駆動型 Beans によるメッセージの並行処理を実装できる

> メッセージ駆動型 Bean はステートレスのサービスを表します。これは、完全に匿名で、クライアントに識別情報を公開しない非同期メッセージコンシューマです。メッセージ駆動型 Bean は、ホームインタフェースもコンポーネントインタフェースも持ちません。クライアントは、メッセージ駆動型 Bean クラスが MessageListener である Java Message Service の送信先 (キューまたはトピック) にメッセージを送信することにより、Java Message Service を介してメッセージ駆動型 Beans にアクセスします。

> メッセージ駆動型 Beans のみが、非同期でメッセージを受け取ることができます。セッション Beans やエンティティ Beans は、Java Message Service の MessageListener にはなれません。

> メッセージ駆動型 Beans には次の特性があります。

> - 1 つのクライアントメッセージを受信すると実行される
> - 非同期的に呼び出される
> - 比較的短命である
> - 直接データベース内の共有データを表すわけではないが、このデータのアクセスおよび更新は可能である
> - EJB サーバーのクラッシュ時に削除される
> - ステートレスである
> - トランザクション対応 (オプション)

> ### EJB コンテナの設定

> EJB コンテナのログレベルを設定できます。また、監視を有効にすることも可能です。EJB コンテナは、EJB と MDB の両方を処理します。コンテナが管理する EJB と MDB については、管理インタフェースを使って設定できます。この節には次の項目があります。

> - 一般設定
> - EJB 設定
> - MDB プールの設定

> #### 一般設定

> EJB コンテナに関して次の項目を設定します。

> - ログ
> - 監視
> - トランザクション属性

> EJB コンテナのログレベルの設定、監視の有効化、およびトランザクション属性の設定を行うには、次の手順に従います。

> 1. 管理インタフェースの左側のペインで、管理インタフェースSun ONEインスタンスツリーを展開して、変更する EJB コンテナ設定を探します。
> 2. コンテナのリストを表示し、ここから「EJB コンテナ」を選択します。管理インタフェースの右側のペインに、次のような EJB コンテナの一般設定用のウィンドウが表示されます。

> 図 8-3 EJB コンテナの一般設定

> 1. 「監視を有効」のチェックボックスにチェックマークをつけて、EJB コンテナの監視を有効にします。これで、指定したSun ONE Application Serverインスタンスの EJB コンテナの監視が有効になりました。EJB コンテナの監視可能な項目については、EJB コンテナ統計管理情報の表を参照してください。
> 2. 「ログレベル」ドロップダウンリストからログレベルを選択します。すべてのログレベルおよびその定義を表示するには、第 5 章「ログの使用」ログレベルを指定して、ログに記録するメッセージの種類を制御します。たとえば、ログレベル FATAL のメッセージだけを記録するように指定した場合、このレベルより上のレベルのメッセージは無視されます。明示的に指定されたログレベルで記録されるメッセージだけが、この値と比較されます。

> 明示的に指定されてないログレベルで記録されたメッセージは、無条件に記録されます。デフォルトでは、すべての警告、エラー、致命的なメッセージが記録されます。

> 3. 「コミットのオプション」ドロップダウンリストで、EJB コンテナに使用する「コミットのオプション」を選択します。

> トランザクションの終了方法には、コミットまたはロールバックによる 2 種類があります。トランザクションがコミットすると、ステートメントによって変更されたデータは保存されます。Enterprise JavaBean の設計時には、コミットがコンテナ管理のトランザクションと Bean 管理のトランザクションのどちらであるかを決めます。ドロップダウンリストの選択肢では、「B」は Bean 管理のコミットを、「C」はコンテナ管理のコミットを示しています。

> 4. 「プロパティ」ボタンをクリックして、EJB コンテナの新しいプロパティを作成します。
> 5. 「了解」をクリックして、設定を保存します。

> 監視可能な EJB コンテナの属性を次の表に示します。

> 表 8-1 EJB コンテナ統計管理情報

> 統計情報の名前 | データ型、単位 | 値の範囲 | コメント
> --- | --- | --- | ---
> minBeansInPool | 整数 | 0 〜 MAXINT | プール内の Beans の最小数 (ステートレスのセッション Beans に適用)
> initialBeansInPool | 整数 | 0 〜 MAXINT | プール内の Beans の初期数 (ステートレスのセッション Beans に適用)
> maxBeansInPool | 整数 | 0 〜 MAXINT | プール内のBeans の最大数 (ステートレスのセッション Beans に適用)
> beanIdleTimeoutInSeconds | 整数 | 0-MAXLONG | Bean が削除されるまでのアイドルタイムアウト (秒数)
> numBeansCreated | 整数 | 0 〜 MAXINT | これまでに作成された Beans 数
> numBeansDestroyed | 整数 | 0 〜 MAXINT | これまでに削除された Beans 数
> numThreadsWaitaing | 整数 | 0 〜 MAXINT | 利用可能な Beans を待機しているスレッド数
> numBeansInPool | 整数 | 0 〜 MAXINT | プール内の利用可能な Beans 数 (この値が 0 より大きい場合、numThreadsWaiting は必ず 0)
> maxBeansInCache | 整数 | 0 〜 MAXINT | キャッシュ内の Beansの最大数 (エンティティ Beans およびステートフル Bean に適用)
> minBeansInCache | 整数 | 0 〜 MAXINT | キャッシュ内の Beans の最小数 (エンティティ Beans およびステートフル Beans に適用)
> cacheFaultsPercentage | 倍精度浮動小数点数 |  | バックアップストアからのアクティブ化によるキャッシュミスの回数

> #### EJB 設定

> 管理インタフェースを使うと、EJB コンテナに管理される EJB のデフォルトのプールと Bean キャッシュに関する設定を行うことができます。次の各項目で説明します。

> - EJB プールを設定するには
> - EJB キャッシュを設定するには

> ##### EJB プールを設定するには

> EJB プール設定を行うには、次の手順に従います。

> 1. 管理インタフェースの左側のペインで、EJB 設定を変更するSun ONE Application Serverインスタンスツリーを展開します。
> 2. コンテナのリストを表示し、ここから「EJB コンテナ」を選択します。管理インタフェースの右側のペインに、次のような EJB プールの設定用のウィンドウが表示されます。

> 図 8-4 EJB プールの設定

> 1. 「通常プールサイズ」フィールドに、プール内の Beans の最小数を指定します。これは、ステートレスのセッション Beans に適用されます。
> 2. 「最大プールサイズ」ドロップダウンリストに、任意の時点でプール内に格納できる Beans の最大数を指定します。この設定は、ステートレスのセッション Beans に適用されます。
> 3. 「プールサイズ変更量」フィールドに、Beans が idle-timeout-in-seconds タグで指定された時間を超えてアイドル状態であった場合にプールから削除される Beans 数を指定します。
> 4. 「アイドルタイムアウト (秒)」フィールドに、Bean がアイドル状態で残ることができる期間を秒単位で指定します。アイドルタイムアウトの期間が経過してもアイドル状態のままである Bean は削除されます。
> 5. 「保存」をクリックして変更を保存します。

> ##### EJB キャッシュを設定するには

> EJB キャッシュ設定を行うには、次の手順に従います。

> 1. 管理インタフェースの左側のペインで、EJB 設定を変更するSun ONE Application Serverインスタンスツリーを展開します。
> 2. コンテナのリストを表示し、ここから「EJB コンテナ」を選択します。管理インタフェースの右側のペインに、次のような EJB プールの設定用のウィンドウが表示されます。

> 図 8-5 EJB キャッシュの設定

> 1. 「最大キャッシュサイズ」フィールドに、キャッシュに保持される Beans の最大数を指定します。この属性のデフォルト値は、idle-timeout-in-seconds 属性に指定されています。
> 2. 「キャッシュサイズ変更量」フィールドに、プール内の Beans 数が Max Cache Size 属性に指定された量を超えた場合に削除する Beans 数を指定します。
> 3. 「削除タイムアウト (秒)」フィールドに、バックアップストア内でアイドル状態の Bean が非活性化されたままでいられる時間を指定します。Bean がクライアントからアクセスされない期間が removal-timeout-in-seconds 属性に指定された値を経過すると、Bean はバックアップストアから削除されるため、それ以降クライアントはアクセスできなくなります。
> 4. 「犠牲の選択の方針」ドロップダウンリストで、プールからの削除時に犠牲 (削除対象) となる Beans を選択するためのアルゴリズムを指定します。
> 5. 「アイドルタイムアウト (秒)」フィールドに、Bean がキャッシュ内でアイドル状態でいられる期間を指定します。この期間を過ぎると Bean は削除されます。Bean をアイドルバックアップストアに非活性化の状態で残す期間は、removal-timeout-in-seconds パラメータによって制御されます。
> 6. 「保存」をクリックして変更を保存します。

> #### MDB プールの設定

> 管理インタフェースを使うと、EJB コンテナが管理する MDB のデフォルトのプール設定を行うことができます。MDB のデフォルトのプール設定を行うには、次の手順に従います。

> 1. 管理インタフェースの左側のペインで、変更する MDB コンテナ設定を含むSun ONE Application Serverインスタンスツリーを開きます。
> 2. コンテナのリストを表示し、ここから「EJB コンテナ」を選択します。管理インタフェースの右側のペインに、次のような MDB プールの設定用のウィンドウが表示されます。

> 図 8-6 MDB プールの設定

> 1. 「MDB 設定」をクリックします。「通常プールサイズ」テキストフィールドに、プール内の Beans の最小数を指定します。これは、ステートレスのセッション Beans に適用されます。
> 2. 「最大プールサイズ」フィールドに、任意の時点でプール内に格納できる Beans の最大数を指定します。
> 3. 「プールサイズ変更量」フィールドに、Beans が idle-timeout-in-seconds タグで指定された時間を超えてアイドル状態であった場合にプールから削除される Beans 数を指定します。
> 4. 「アイドルタイムアウト (秒)」フィールドに、Bean がアイドル状態で残ることができる期間を秒単位で指定します。アイドルタイムアウトの期間が経過してもアイドル状態のままである Bean は削除されます。
> 5. 「保存 」をクリックして設定を保存します。

> 前へ 目次 索引 次へ

> Copyright 2003 Sun Microsystems, Inc. All rights reserved.