アプリケーション・モジュール・プールのチューニング

57 アプリケーション・モジュール・プールのチューニング

この章では、ADFビジネス・コンポーネントのアプリケーション・モジュール・プールの動作方式と、アプリケーション・モジュール・プールをチューニングしてアプリケーションのパフォーマンスを最適化する方法について説明します。

この章の内容は次のとおりです。

アプリケーション・モジュール・プールについて

ADFアプリケーション・モジュール・プールとは、複数のアプリケーション・クライアントによって共有される単一のアプリケーション・モジュール・タイプのインスタンスの集合です。Webページの送信間の時間をあけると、より少数のアプリケーション・モジュール・コンポーネントでより多数のアクティブ・ユーザーを処理できます。この場合、メモリー使用量が減少し、パフォーマンスが向上します。

アプリケーション・モジュール・プールは、同じタイプのアプリケーション・モジュール・ランタイム・インスタンスのコレクションです。そこにアクセスするユーザー数をプロビジョニングするために、実行時に1つ以上のアプリケーション・モジュール・インスタンスをプールからサービス・ユーザーに提供するように、Fusion Webアプリケーションを構成できます。

プール内の各アプリケーション・モジュール・インスタンスは、複数のブラウザ・クライアントで共有されます。これらのクライアントの標準的な「思考時間」(Webページを送信する間隔)により、アプリケーション・モジュール・コンポーネントの数がシステムで作業しているアクティブ・ユーザーの総数よりも効果的に小さくなるように最適化されます。たとえば、20人のユーザーがそれぞれのブラウザからWebサイトにアクセスしている場合、これらのユーザーと同数のアプリケーション・モジュール・インスタンスではなく、5個または10個のアプリケーション・モジュール・インスタンスでサービスを提供できる可能性があります。つまり、プールは使用可能なアプリケーション・モジュールの数を上回るユーザーにサービスを提供できるだけでなく、この小さなアプリケーション・モジュールのセットへのサービス提供のために中間層が必要とするメモリーが少なくて済むので、ADFアプリケーションを、制限のあるハードウェア・リソース上でさらに拡大可能になります。

設計時の構成を通して、アプリケーション・モジュールを使用すると、完全にステートレスなFusion Webアプリケーションをサポートしたり、複数のブラウザ・ページにまたがる作業ユニットをサポートしたりできます。パフォーマンスを最適化するために、あるアプリケーション・モジュールのインスタンスが「状態管理」モードでプールに返された場合、プールは該当するアプリケーション・モジュールに対するセッション参照を追跡します。このアプリケーション・モジュールのインスタンスはそのままプールに残り、使用できる状態ですが、「セッション・アフィニティ」を維持することによりパフォーマンスが向上するため、前回このインスタンスを使用していたセッションによる使用が望ましいでしょう。

そのため、プール内のアプリケーション・モジュールのインスタンスはどの時点においても、その状態を反映して、次の3つのグループに論理的に分類されます。

プールにチェックインされて、無条件に使用可能
プールにチェックインされて使用可能だが、アクティブ・ユーザー・セッションによるセッション・アフィニティの再利用のため参照される
プールからチェックアウトされ、かつ使用不可能。Webコンテナ内のなんらかのスレッドにより現在(まさにその瞬間に)使用されているため

アプリケーション・モジュール・プーリングを最大限に活用するには、背後で行われていることを理解しておく必要があります。アプリケーション・モジュールのセッション状態管理の詳細は、「受動化とアクティブ化が行われるタイミングの管理」を参照してください。

アプリケーション・モジュール・プールの動作に影響を与えるために設計時に設定できる構成パラメータの詳細は、「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」を参照してください。

アプリケーション・モジュール・プール

アプリケーション・モジュール・コンポーネントは実行時、次の2つの方法で使用できます。

クライアントから直接アクセスされるアプリケーション・モジュールとして使用する
別のアプリケーション・モジュール・インスタンスの中に集約(ネスト)されている再利用可能なコンポーネントとして使用する

クライアントがこれに直接アクセスするときのアプリケーション・モジュールはルート・アプリケーション・モジュールと呼ばれます。クライアントは、クライアントが含むアプリケーション・モジュール・インスタンスの一部として、ネストされているアプリケーション・モジュールに間接的にアクセスします。同一のアプリケーション・モジュールを実行時にこれら両方の方法で使用することも可能ですが、それは一般的ではありません。重要な点は、ADFビジネス・コンポーネントが作成するのは、ルート・アプリケーション・モジュールに対するアプリケーション・モジュール・プールのみであるということです。

基本的には、各Java VMのFusion Webアプリケーションにより使用されるルート・アプリケーション・モジュール1つにつき、アプリケーション・モジュール・プールが1つ作成されます。これらのJava VMでは、そのタイプのルート・アプリケーション・モジュールがADFコントローラ・レイヤーにより使用されます。アプリケーションが必要とするアプリケーション・モジュール・プールの数に関連する詳細トピックは、「デプロイメント環境のシナリオとプーリング」を参照してください。

デプロイメント環境のシナリオとプーリング

アプリケーションが利用するプールの数やプールの型は、ターゲット・プラットフォームの構成によって異なります。たとえば、アプリケーション・ユーザーのWebリクエストにサービスを提供するために利用できるJava仮想マシン(JVM)が複数あるかどうかや、Oracle WebLogic Serverドメインが複数あるかどうかで変わります。このアプリケーションにおいて、実行時のJVMが1つのシナリオと複数のシナリオで、どの種類のプールがいくつ作成されるのかを理解するために、次の想定を見直してみます。

Fusion WebアプリケーションでHRModuleおよびPayablesModuleという2つのアプリケーション・モジュールを使用する。
ユーザー・アプリケーション内で値リストをサポートするためによく使用される一連のビュー・オブジェクトがCommonLOVModuleに含まれており、HRModuleにもPayablesModuleにもよく使用されるLOVビュー・オブジェクトにアクセスするためにCommonLOVModuleのインスタンスがネストされている。
HRModuleおよびPayablesModuleは、appuserという名前の同一のJDeveloper接続定義を使用するように構成済である。

Oracle WebLogic Serverドメインが1つ、Oracle WebLogic Serverインスタンスが1つ、JVMが1つの場合

Oracle WebLogic Serverインスタンスが1つという構成で、このアプリケーションを単一のOracle WebLogic Serverドメインにデプロイすると、アプリケーション・ユーザーからのWebリクエストにサービスを提供する場合に利用可能なJava VMは1つのみになります。

HRModuleおよびPayablesModuleにアクセスするWebページを全ユーザーが利用するものと仮定すると、次のようになります。

HRModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ
PayablesModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ

Java VMが1つであるこの場合は、全部でアプリケーション・モジュール・プールが2つになります。

ノート:

再利用可能なCommonLOVModuleのネストされたインスタンスに対して、アプリケーション・モジュール・プールは存在しません。CommonLOVModuleのインスタンスは、HRModuleおよびPayablesModuleのインスタンスにより、それぞれのアプリケーション・モジュール・プール内でラップされます。

Oracle WebLogic Serverドメインが複数、Oracle WebLogic Serverインスタンスが複数、JVMが複数の場合

次は、Java VMが複数関与するデプロイ環境を考えてみます。フロントエンドとしてハードウェア・ロードバランサを設け、4台の異なる物理マシンを2つのOracle WebLogic Serverドメインとして構成してあるものとします。4台のマシン上で、各Oracle WebLogic Serverインスタンスがそれぞれ1つのJVMを持ちます。アプリケーションのユーザーがアプリケーションにアクセスすると、そのリクエストはこれら2つのOracle WebLogic Serverドメインによって共有され、各ドメインの中では該当するOracle WebLogic Serverインスタンスから利用可能な2つのJVMによって共有されます。

この場合も、HRModuleおよびPayablesModuleにアクセスするWebページを全ユーザーが利用するものと仮定すると、次のようになります。

HRModuleのアプリケーション・モジュール・プールは4つ(4つの各JVMごとに1つ)

(1つのHRModuleルート・アプリケーション・モジュール)×(2つのOracle WebLogic Serverドメイン)×(各2つのOracle WebLogic Server JVM)
PayablesModuleのアプリケーション・モジュール・プールは4つ(4つの各JVMごとに1つ)

(1つのPayablesModuleルート・アプリケーション・モジュール)×(2つのOracle WebLogic Serverドメイン)×(各2つのOracle WebLogic Server JVM)

この場合は、全部で8つのアプリケーション・モジュール・プールが4つのJVMに存在することになります。

「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」でアプリケーション・モジュール・プールの構成パラメータをいろいろと確認する場合、それらのパラメータは1つのJVM内で指定した単一のアプリケーション・モジュールの特定の1つのアプリケーション・モジュール・プールに適用されることに注意してください。

ロード・バランシングによりユーザー・リクエストはOracle ADFが実行されている複数のJVMに分散されるため、各JVMにある個々のアプリケーション・モジュール・プールは、ユーザー負荷のn分の1をサポートする必要があります。ここで、nには、ユーザー・リクエストへのサービス提供に使用できるJVMの数です。Java VMの数を念頭に置いて、アプリケーション・モジュール・プールの適切な値を設定する必要があります。基本的には、負荷テストとアプリケーション・モジュール・プーリング統計の結果をサイズに関するパラメータの基準とし、次にその合計をプール数nで割ります。この数は、アプリケーション・サーバー・ドメインとOracle WebLogic Serverインスタンスの使用状況に基づいて決定されます。たとえば、1つのプールにあるアプリケーション・モジュール数の最小値を10に設定しようと決めたが、このアプリケーションにサービスを提供しているOracle WebLogic Serverインスタンスが5つあるため最終的なプール数は5になったという場合、このパラメータは10 (1つのJVMにある指定されたアプリケーション・モジュールのみにサービスを提供)ではなく2 (10を5で割った商)に設定します。

使用可能なサイズ指定に関するパラメータの詳細は、「プールのサイズ指定に関するパラメータ」を参照してください。

プール構成パラメータの設定

ADFアプリケーションで構成パラメータを設定することにより、アプリケーション・モジュール・プールの実行時動作を制御できます。アプリケーション・モジュール・プール構成パラメータには、プールの動作、プールのサイズ指定、プールのクリーンアップ動作という3つの論理カテゴリがあります。

アプリケーション・モジュール・プールの実行時動作は、適切な構成パラメータの設定により制御します。それらのパラメータは、アプリケーション・モジュールの構成で宣言的な設定を行ったり、Java Systemパラメータとして指定したり、または実行時にプログラムで設定したりできます。

構成プロパティの宣言的設定方法

個々のアプリケーション・モジュールの実行時構成プロパティを表示および設定するには、アプリケーション・モジュール構成の概要エディタの「データベースとスケーラビリティ」タブを使用します(図57-1)。

図57-1 「構成の編集」ダイアログの「データベースとスケーラビリティ」タブ

「図57-1 「構成の編集」ダイアログの「データベースとスケーラビリティ」タブ」の説明

始める前に:

アプリケーション・モジュール・プーリングの知識があると役立ちます。詳細は、「プール構成パラメータの設定」を参照してください。

アプリケーション・モジュールの構成パラメータについて理解します。アプリケーション・モジュール・プールのチューニング用の構成パラメータの詳細は、「アプリケーション・モジュール・プールの構成パラメータに関する必知事項」を参照してください。

予測されるレベルの使用量に関して、Fusion Webアプリケーションのチューニングに役立つベスト・プラクティス・ガイドラインは、『パフォーマンスのチューニング・ガイド』の「Oracle Application Development Frameworkのチューニング」を参照してください。

アプリケーションでJDBC URL接続タイプ(レガシーのみ)を定義する場合、このガイドの11g リリース・バージョンを参照して、ADFデータベース接続プールの構成パラメータに関するドキュメントを取得してください。

アプリケーション・モジュールのプーリング構成を編集するには:

「アプリケーション」ウィンドウで、アプリケーション・モジュールをダブルクリックします。
概要エディタで、「構成」ナビゲーション・タブをクリックします。
「構成」ページで、編集する構成の構成ハイパーリンクをクリックします。
アプリケーション・モジュール構成の概要エディタで、「データベースとスケーラビリティ」タブをクリックして必要な実行時プロパティを編集し、「OK」をクリックして構成の変更内容を保存します。

構成プロパティを宣言的に設定した場合の処理

アプリケーション・モジュール構成の概要エディタで指定した値は、アプリケーション・モジュールのXML定義を基準とする./commonサブディレクトリ内のbc4j.xcfgというXMLファイルに保存されます。同一のJavaパッケージ内の全アプリケーション・モジュールの構成はすべて、この同じファイルに保存されます。通常は、bc4j.xcfgファイルを直接変更するのではなく、概要エディタを使用して特定のアプリケーション・モジュールの構成の設定を変更します。アプリケーション・モジュール構成の概要エディタを表示するには、「アプリケーション」ウィンドウでアプリケーション・モジュールをダブルクリックして、概要エディタの「構成」ナビゲーション・タブを選択します。次に、概要エディタの「構成」ページで構成を選択し、構成のハイパーリンクをクリックします。

たとえば、SummitADFアプリケーションに含まれるBackOfficeAppModuleアプリケーション・モジュールのアプリケーション・モジュール構成(./src/oracle/summit/model/services/commonディレクトリ内のbc4j.xcfgファイル)の概要エディタを見ると、BackOfficeAppModuleアプリケーション・モジュール用の2つの名前付き構成が含まれています。この場合、次の例のようにBackOfficeAppModuleLocal構成とBackOfficeAppModuleShared構成は、Oracle ADFモデル・テスターがJDBC URL接続を使用するように指定しています。JDBC接続の接続詳細は、プロジェクト・ディレクトリとの相対位置指定で./.adf/META-INFと記述されるサブディレクトリにあるconnections.xmlファイルにあります。

<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
...
   <AppModuleConfigBag
      ApplicationName="oracle.summit.model.services.BackOfficeAppModule">
      <AppModuleConfig 
            name="BackOfficeAppModuleLocal"
            jbo.project="oracle.summit.model.Model"
            ApplicationName="oracle.summit.model.services.BackOfficeAppModule"
            DeployPlatform="LOCAL" JDBCName="summit_adf">
         <Database jbo.TypeMapEntries="Java"/>
         <Security
            AppModuleJndiName="oracle.summit.model.services.BackOfficeAppModule"/>
      </AppModuleConfig>
      <AppModuleConfig
            name="BackOfficeAppModuleShared"
            jbo.project="oracle.summit.model.Model"
            ApplicationName="oracle.summit.model.services.BackOfficeAppModule"
            DeployPlatform="LOCAL" JDBCName="summit_adf">
         <AM-Pooling jbo.ampool.maxpoolsize="1"
                     jbo.ampool.isuseexclusive="false"/>
         <Database jbo.TypeMapEntries="Java"/>
         <Security
            AppModuleJndiName="oracle.summit.model.services.BackOfficeAppModule"/>
      </AppModuleConfig>
   </AppModuleConfigBag>
</BC4JConfig>

ここで、<AppModuleConfig>タグの子要素の属性にはjboで始まる名前が付けられています。これは、そのADFビジネス・コンポーネント・プロパティの名前と一致しています(たとえば、<AM-Pooling>タグは、プロパティjbo.ampool.maxpoolsizeに対応する属性jbo.ampool.maxpoolsizeを定義します)。また、アプリケーション・モジュール構成エディタで、あるプロパティが実行時のデフォルト値に設定されている場合、JDeveloperはこのエントリをbc4j.xcfgファイルに書き込まないことを理解しておくことも重要です。

構成プロパティをプログラム的に設定する方法

実行時にアプリケーションによってアプリケーション・モジュール構成プロパティを制御する必要がある場合は、ADFビジネス・コンポーネントAPIを使用してこれらのプロパティを動的に設定できます。たとえば、一般的なADFアプリケーションでは、アプリケーション・モジュールによって静的なJDBCデータソースが構成されます。しかし、アプリケーションで、ユーザーに応じて様々なデータベースからデータを表示する必要がある場合、データソース名とアプリケーション・モジュール・プールのパラメータを実行時に設定することがあります。

oracle.jbo.common.ampoolパッケージにEnvInfoProviderインタフェースを実装するJavaクラスを作成すると、構成プロパティをプログラムによって設定できます。クラス内では、次の例に示すように、getInfo()メソッドをオーバーライドしてput()をコールし、渡される環境ハッシュ表に値を格納します。

package devguide.advanced.customenv.view;
import java.util.Hashtable;
import oracle.jbo.common.ampool.EnvInfoProvider;
/**
 * Custom EnvInfoProvider implementation to set
 * environment properties programmatically
 */
public class CustomEnvInfoProvider implements EnvInfoProvider {
  /**
   * Overridden framework method to set custom values in the
   * environment hashtable.
   * 
   * @param string - ignore
   * @param environment Hashtable of config parameters
   * @return null - not used
   */
  public Object getInfo(String string, Object environment) {
    Hashtable envHashtable = (Hashtable)environment;
    envHashtable.put("some.property.name","some value");
    return null;
  }
  /* Required to implement EnvInfoProvider */
  public void modifyInitialContext(Object object) {}
  /* Required to implement EnvInfoProvider */
  public int getNumOfRetries() {return 0;}
}

ConfigurationクラスのcreateRootApplicationModule()メソッドを使用してステートレスなクライアントまたはコマンド行クライアント用のアプリケーション・モジュールを作成する場合は、カスタムなEnvInfoProviderを第2引数(オプション)として渡すことができます。カスタムなEnvInfoProviderをADF Webベース・アプリケーションで使用するには、次の例で示すように、セッションCookieファクトリのカスタム・クラスを実装する必要があります。カスタムなセッションCookieファクトリを使用するには、構成プロパティjbo.ampool.sessioncookiefactoryclassに、セッションCookieファクトリのカスタム・クラスの完全修飾名を設定します。

package devguide.advanced.customenv.view;
import java.util.Properties;
import oracle.jbo.common.ampool.ApplicationPool;
import oracle.jbo.common.ampool.EnvInfoProvider;
import oracle.jbo.common.ampool.SessionCookie;
import oracle.jbo.http.HttpSessionCookieFactory;
/**
 * Example of custom http session cookie factory
 * to install a custom EnvInfoProvider implementation
 * for an ADF web-based application.
 */
public class CustomHttpSessionCookieFactory
       extends HttpSessionCookieFactory {
  public SessionCookie createSessionCookie(String appId,
                                           String sessionId, 
                                           ApplicationPool pool,
                                           Properties props) {
    SessionCookie cookie =
      super.createSessionCookie(appId, sessionId,pool, props);
    EnvInfoProvider envInfoProv = new CustomEnvInfoProvider();
    cookie.setEnvInfoProvider(envInfoProv);
    return cookie;
  }
}

次に、oracle.jbo.http.HttpSessionCookieFactoryクラスを含むJARファイルをプロジェクト・ファイルに追加します。JARファイルadfmweb.jarは[JDEV_INSTALL]\Oracle_common\modules\oracle.adf.model\ディレクトリにあります。このファイルは、ライブラリではADF Webランタイムとも呼ばれます。JARファイルを追加するには、次のステップを実行します。

プロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「ライブラリとクラスパス」を選択します。
「ライブラリの追加」をクリックします。
「ADF Webランタイム」を選択して、「OK」をクリックします。

ノート:

JARファイルを追加しないと、データ・ソース名とアプリケーション・モジュール・プールのパラメータが実行時に動的に設定されるようにjbo.envinfoproviderを設定している場合に、IDEでエラーが表示されます

構成プロパティのスコープに関する必知事項

ADFビジネス・コンポーネントが使用する各ランタイム構成プロパティには、スコープが1つあります。各プロパティのスコープは、該当するプロパティ値が評価されるタイミングと、その値が単一のJava VM内で効果的に共有される(すなわち静的である)か否かを示します。ADFビジネス・コンポーネントのPropertyManagerクラスは、サポートされているすべてのプロパティから構成されるレジストリです。定義されるのは、プロパティの名前、デフォルト値およびスコープです。このクラスにはmain()メソッドが含まれているので、該当クラスをコマンド行から実行して、全構成プロパティ情報のリストを表示できます。

JDEVHOMEがJDeveloperのインストール・ディレクトリである場合、この一連の設定値のリストを表示するには、次のコマンドを実行します。

$ java -cp JDEVHOME/BC4J/lib/bc4jmt.jar oracle.jbo.common.PropertyManager

このコマンドを発行すると、ADFビジネス・コンポーネントの構成プロパティがすべてコンソールに送られます。また、構成プロパティ値を設定できる様々なレベルおよびそれらのレベルの優先度を示す便利な参考情報もリスト表示されます。

---------------------------------------------------------------
Properties loaded from following sources, in order:
1. Client environment [Provided programmatically
                       or declaratively in bc4j.xcfg]
2. Applet tags
3. -D flags (appear in System.properties)
4. bc4j.properties file (in current directory)
5. /oracle/jbo/BC4J.properties resource
6. /oracle/jbo/commom.jboserver.properties resource
7. /oracle/jbo/common.Diagnostic.properties resource
8. System defined default
---------------------------------------------------------------

どのプロパティも、次のいずれか1つのスコープとともにリスト表示されます。

MetaObjectManager

このスコープのプロパティは、ADF PropertyManagerが初めて初期化される際、Java VMごとに一度初期化されます。
SessionImpl

このスコープのプロパティは、ApplicationModule.prepareSession()が起動されるたびに一度初期化されます。
Configuration

このスコープのプロパティは、アプリケーション・モジュール・プールが初めて作成され、該当するアプリケーション・モジュールの構成が初めて読み込まれるときに初期化されます。
Diagnostic

このスコープのプロパティは、ADFビジネス・コンポーネントの組込み診断機能に固有なものです。

これらのどのスコープでも、一連のプロパティが初期化される際に、前述のレイヤー化された値の解決が実行されます。クライアント環境(解決順序のレベル1)でプロパティ値が指定されていれば、これらが初期化されたときには必ず、システム・パラメータ(解決順序レベル3)に指定された値よりも優先されます。

クライアント環境は、プログラムで移入できるか、ロード時にConfigurationオブジェクトによって自動的に移入される名前/値ペアのハッシュ表であり、bc4j.xcfgファイルのエントリにその名前/値ペアが含まれます。つまり、MetaObjectManagerレベルでスコープの対象となるプロパティの場合は、次の両方の処理を実行するのが、該当する一連のプロパティに対し全アプリケーション・モジュールで同じデフォルト値を確実に使用するための最も信頼性の高い方法です。

該当するプロパティ値が、どのアプリケーション・モジュールのbc4j.xcfgファイルの構成名/値のペア・エントリにも表示されないようにする。
実行環境内のJavaシステム・プロパティを使用してプロパティ値を設定する。

そのかわり、もし、MetaObjectManagerスコープのプロパティをbc4j.xcfgファイルに残した場合、Java VMの起動後にプールが作成される最初のアプリケーション・モジュールの構成に指定された値に対して望ましくない処理が行われます。

アプリケーション・モジュール・プールの構成パラメータに関する必知事項

アプリケーション・モジュール・プールの構成パラメータは、プールの動作、プールのサイズ指定およびプールのクリーンアップ動作に関連する3つの論理的カテゴリに分類されています。デフォルトでは、Fusion Webアプリケーションにより、アプリケーション・モジュール・プーリングが有効になります。

プールの動作に関するパラメータ

アプリケーション・モジュールは、アプリケーション・モジュール・プールの動作に影響を与える構成パラメータを定義し、インスタンスがアプリケーション・モジュール・プールから削除された後、アプリケーション・モジュール・インスタンスが、接続プールから取得するJDBC接続を保持するかどうかを定義します。

ADFアプリケーション・モジュール・プールがデータベース接続プールを使用する方法は、「解放時にアプリケーション・モジュールの切断」の構成パラメータjbo.doconnectionpoolingの設定によって異なります。図57-1に示すように、デフォルトでは設定は無効であり、パラメータの設定はjbo.doconnectionpooling=falseになっています。

ノート:

jbo.doconnectionpooling=falseと設定しても、データベース接続プーリングが実行されないわけではありません。これは、アプリケーション・モジュール・プールに戻されるときのチェックインの際、アプリケーション・モジュールがそのJDBC接続から切断されないという意味です。

アプリケーション・モジュール・インスタンスをアプリケーション・モジュール・プールで作成すると、JDBC接続が取得されます。デフォルトでは、1人のユーザーのリクエスト全体にわたって、ADFは同じアプリケーション・モジュール・インスタンス(その関連するメモリーとJDBC接続および状態を含む)を試して再利用するようにセッション・アフィニティの維持を優先します。目的はこのようなユーザーのパフォーマンス速度の向上です。jbo.doconnectionpooling=falseのデフォルト設定によってこの動作が有効になり、アプリケーション・モジュール・インスタンスは、クライアントによる以降のリクエスト全体にわたって、そのJDBC PreparedStatementオブジェクトのキャッシュ化と再利用を維持できます。

ただし、Fusion Webアプリケーションにアクセスするユーザー数が増加するにつれて、JDBC接続、PREPARE文および結果セットを保持するサーバーへのメモリー要求が増します。数千のユーザーに対応するようにアプリケーション・モジュール・プールを構成する場合、各リクエスト後にJDBC接続を解放しないと、サポートされる管理対象ユーザー・セッションの一部を含め、サーバー負荷が高まる可能性があります。この状況は、Oracle Database 10g以降のOracle JDBCドライバと同様に、メモリー消費を超えてパフォーマンスを最適化するデータベース・ドライバを使用するように構成されるデプロイメント環境で特に顕著です。

JDBCドライバによってサーバー・メモリーがすぐに消費される状況を回避するには、jbo.doconnectionpooling=trueを設定してアプリケーション・モジュール・インスタンス接続のデフォルト動作をオーバーライドできます。ユーザー・セッションがアプリケーション・モジュールの使用を終える(通常は各HTTPリクエストの終了時)たびに、アプリケーション・モジュール・インスタンスが、該当するリクエストで使用していたJDBC接続との関係を断ち、その接続をJDBC接続プールに返します。該当するアプリケーション・モジュール・インスタンスは、ユーザー・セッションによって次回使用されるとき、JDBC接続プールからJDBC接続を再度取得し、該当するアプリケーション・モジュールがアプリケーション・モジュール・プールからチェックアウトされている期間(この場合も、通常は1つのHTTPリクエストの期間)、そのJDBC接続を使用します。アプリケーション・モジュール・インスタンス自体で、PreparedStatementの作成に使用されたJDBC接続オブジェクトを切断するため、この状況では、アプリケーション・モジュールがプールからチェックアウトされるたびにprepareSession()メソッドが起動され、データベース状態を初期化しなおすことができます。そのため、JDBC接続の解放をセッションに対して有効にする場合は、データベース接続の総数が少なくなるかわりに、JDBCを毎回セットアップするオーバーヘッドが少し増えます。

アプリケーション接続のために、基礎となる同一のデータベース・ユーザーを多数のアプリケーション・モジュール・プールがすべて使用する場合、違いが顕著になります。

50個の異なるアプリケーション・モジュール・プールがそれぞれアプリケーション・モジュール・インスタンスを内部に1つだけ持つ場合、jbo.doconnectionpooling=falseという条件では、50個のJDBCアプリケーション接続が使用されます。「最小使用可能サイズ」の構成パラメータjbo.ampool.minavailablesize=0を設定し、適切なインスタンス・アイドル・タイムアウトが経過した後にアプリケーション・モジュール・プールを0インスタンスまで減らせるようにアプリケーション・モジュール・プーリングのサイズ・パラメータを設定すると、アプリケーション・モジュールは保持していた接続をそのプールから削除されるときに元に戻します。この状況は、管理対象アプリケーション・モジュール・インスタンスの数が少ないままの場合、ピーク需要時以外、または少数の同時ユーザーをアプリケーションがサポートする必要がある場合に最適です。
対照的に、50個の異なるアプリケーション・モジュール・プールがそれぞれ1つのアプリケーション・モジュール・インスタンスを持ち、jbo.doconnectionpooling=trueであった場合、使用中のJDBC接続の数は、これらのアプリケーション・モジュールのうち、異なるクライアントにより同時に使用されているものの数によって変わります。アプリケーション・モジュール・インスタンスは、プール内にあってユーザー・セッションにより使用されていない場合、jbo.doconnectionpooling=trueという条件があるため、そのJDBC接続を接続プールに解放します。そのアプリケーション・モジュール・インスタンスは、別のユーザーによって再度必要とされるかアプリケーション・モジュール・プール・モニターによって最終的にクリーンアップされるまでプール内で待機している間、JDBC接続には接続されていません。この状況は、ピーク需要時または同時ユーザー数の増加が予測される場合にFusion Webアプリケーションのスケーラビリティを確保する際に最適です。

jbo.doconnectionpoolingをtrueに設定すると、「Transaction Disconnect Level」の構成パラメータjbo.txn.disconnect_levelのデフォルト設定1により、対応するJDBC接続への参照がドロップされた後でも、アプリケーション・モジュール、ビュー・オブジェクトおよび行セットをすべてメモリーに残し、有効のままにできます。この構成により、通常は解放時にアプリケーション・モジュールの受動化が実行される、この状況に関連するメモリー要件が軽減されます。かわりに、アクティブ化されるときに、このフレームワークで必要になるのは、カーソル位置の再実行と同期のみです。

あるいは、JDBC接続を保持することと、接続したままにすることのバランスをとるには、「接続しきい値」の構成パラメータjbo.ampool.connection_thresholdを構成します。このパラメータは、結合されたすべてのアプリケーション・モジュール・プール内のアプリケーション・モジュールが、アプリケーション・モジュール・プールのクリーンアップ時に保持する(解放して接続プールに戻さない)最大接続数を指定します。jbo.ampool.connection_thresholdパラメータを最大接続数(0よりも大きな値)に設定した場合、プールのクリーンアップ時にはアプリケーション・モジュールを切断するのが望ましいことを暗黙的に示したことになるため、構成パラメータjbo.doconnectionpoolingを有効にしないようにする必要があることに注意してください。jbo.ampool.connection_thresholdパラメータがアプリケーション・モジュール・プーリングにどのような影響を及ぼすかの詳細は、「アプリケーション・モジュール・プーリングの最適化に関する必知事項」を参照してください。

プールのサイズ指定に関するパラメータ

アプリケーション・モジュールでは、アプリケーション・モジュール・プールのサイズ指定に影響を与える構成パラメータを定義します。プール・モニターがそのリソース・クリーンアップ・パスのいずれかを実行する場合、アプリケーション・モジュール・インスタンスの数を、使用可能な最大および最小サイズ・パラメータで指定する範囲に送ろうとします。

プール・モニターが、未使用でアイドル状態のアプリケーション・モジュール・インスタンスを削除することで最大サイズを下回るようにプール・サイズを減らすことができない場合、タイムアウトしていないアクティブ・インスタンスを削除して、これらのアクティブ・アプリケーション・モジュールの状態を受動化します。「参照プール・サイズ」の構成パラメータjbo.recyclethresholdでは、受動化が行われるときにプール・モニターに残るアクティブ・アプリケーション・モジュールの数を決定します。デフォルトでは、プール・モニターが受動化を開始するときのしきい値は、10アプリケーション・モジュール・インスタンスです。

「最大使用可能プール・サイズ」の構成パラメータjbo.ampool.maxavailablesizeを使用して、プール・モニターによるリソースのクリーンアップ後、プール・サイズの上限範囲を指定できます。通常、同時ユーザー数に基づくデフォルトの最大使用可能サイズ25と、ユーザーがアプリケーション・モジュールのサービスにアクセスする必要がある頻度をオーバーライドします。ただし、サーバー・メモリーがアプリケーション・パフォーマンスの制限要因ではない場合、最大使用可能サイズを任意の大きな値に設定して、アクティブなユーザー・セッションに引き続き結び付けられているアプリケーション・モジュール・インスタンスの受動化とアクティブ化の影響を最小限に抑えることができます。

ノート:

未使用のアプリケーション・モジュール・インスタンスを再生せず、通常のHTTPセッション・タイムアウトのアイドル時間を30分にするようにプールのクリーンアップを構成する場合、プール・サイズに十分大きな値を指定することが特に重要です。プールのクリーンアップの構成の詳細は、「プールの動作に関するパラメータ」を参照してください。

同様に、使用可能なアプリケーション・モジュール・インスタンスのベースラインを確保する場合にデフォルトの5インスタンスでは足りない場合、「最小使用可能プール・サイズ」の構成パラメータjbo.ampool.minavailablesizeを使用して、プール・サイズの下限範囲を指定できます。通常、ピーク使用時以外は、この値を同時ユーザー数と同じになるように設定してください。この値の設定が低すぎると、パフォーマンスに影響を与える可能性があるアプリケーション・モジュール・インスタンスの不要なインスタンス化が行われます。

プールのクリーンアップに関するパラメータ

アプリケーション・モジュールは、プール・モニターがそのリソース・クリーンアップ・パスのいずれかを実行するときに、リソースの再生処理に影響を与える構成パラメータを定義します。

Java VMごとに1つのアプリケーション・モジュール・プール・モニターがバックグラウンド・スレッドで実行し、プールのスキャンを起動して、デフォルトで600000ミリ秒(10分)間隔のクリーンアップを実行します。デフォルトのプール・ポーリング間隔を変更するには、「プール・ポーリング間隔」のパラメータjbo.ampool.monitorsleepintervalを構成できます。

プール・モニターは次の2つの独立した戦略を使用して、どのアプリケーション・モジュール・インスタンスをプールから削除し、使用可能な新しいリソースとして解放可能かを判断します。

アプリケーション・モジュール・プール・モニターは、3600000ミリ秒(1時間、デフォルト値)を超える期間使用されていなかったアプリケーション・モジュール・インスタンスをプールから削除します。これらの未使用のアプリケーション・モジュール・インスタンスは、プールに構成された最小使用可能サイズにかかわらず再生されます。アプリケーション・モジュールに対する最長有効期間をオーバーライドするには、「最長有効期間」の構成パラメータjbo.ampool.timetoliveを設定できます。ただし、ほとんどのFusion Webアプリケーションでは未使用のアプリケーション・モジュール・インスタンスを解放する必要はないため、このパラメータ値を-1に設定できます。
アプリケーション・モジュール・プール・モニターは、600000ミリ秒(10分、デフォルト値)を超える期間アイドル状態であったアプリケーション・モジュール・インスタンスをプールから削除します。このクリーンアップは、プール内のインスタンス数が、使用可能な最小サイズに達すると停止します。10分を超えるアイドル・ユーザー・セッションを許可する場合、「アイドル・インスタンス・タイムアウト」の構成パラメータjbo.ampool.maxinactiveageを使用して、アプリケーション・モジュール・インスタンスのアイドル・タイムアウトをオーバーライドできます。

ベスト・プラクティス:

アプリケーション・モジュール・プールのクリーンアップ・パスの時間間隔を指定するときに、すべてのアプリケーション・モジュールで「プール・ポーリング間隔」の構成パラメータjbo.ampool.monitorsleepintervalの値を同じに設定します。Java VM 1つにつきアプリケーション・モニターのプール・モニターは1つしかありませんので、アプリケーション・モジュール・プール・モニターのポーリング間隔として効果的に使用される値は、アプリケーション・モジュール構成内にあり、作成される最初のアプリケーション・モジュール・プールにより読取られる値です。すべてのアプリケーション・モジュールで同じ値が使用されるように設定すると、この値が予想可能な方法で確実に設定されます。

アプリケーション・モジュール・プーリングの最適化に関する必知事項

JDBC接続を保持することと、接続したままにすることのバランスをとるには、「接続しきい値」の構成パラメータjbo.ampool.connection_thresholdを構成します。このパラメータは、結合されたすべてのアプリケーション・モジュール・プール内のアプリケーション・モジュールがプールの次のクリーンアップ・サイクル時に保持する(解放して接続プールに戻さない)最大接続数を指定します。

接続しきい値のパラメータjbo.ampool.connection_thresholdを有効にする場合(0よりも大きな値)、アプリケーション・モジュール接続は、チェックイン時ではなく、プールのクリーンアップ時に解放されます。クリーンアップ・モニターは、JDBC接続数の合計数が指定のしきい値を下回るまで最後に使用されたアプリケーション・モジュールを切断しようと最善の努力をします。jbo.ampool.connection_thresholdパラメータを有効にすると、アプリケーション・モジュール・プールのクリーンアップの実行タイミングが変わるため、これは、jbo.ampool.connection_threshold=trueパラメータの設定に互換性がないことを表します。

ノート:

プールのクリーンアップ・サイクルでアプリケーション・モジュールを切断するためのしきい値を構成する場合、値がfalse (デフォルト)になるように必ずjbo.doconnectionpoolingを無効にしてください。接続しきい値パラメータは、設定jbo.doconnectionpooling=trueと互換性がありません。これは、この設定により、アプリケーション・モジュールのチェックイン時にJDBC接続が解放されて接続プールに戻され、かつ、この設定をjbo.txn.disconnect_levelパラメータと組み合せて使用すると、ビジネス・コンポーネントがメモリーに残るようになるためです。jbo.doconnectionpoolingパラメータの詳細は、「プールの動作に関するパラメータ」を参照してください。

たとえば、2つのアプリケーション・モジュール・プールの接続しきい値パラメータを10に設定するとします。この場合、アプリケーション・モジュール・プール1には7つのアプリケーション・モジュールがあり、プール2には8つのアプリケーション・モジュールがあるため、JDBC接続の合計は15になります。アプリケーション・モジュール・プールのクリーンアップ・モニターが実行すると、モニターは、5つの接続(15の接続リソース - 接続しきい値10)を再生するように最大限の努力をします。モニターは、各プールの接続済アプリケーション・モジュールの総数に比例してアプリケーション・モジュールを切断します。この場合、各プールのアプリケーション・モジュール接続の1/3 (5/15)が切断されます。そのため、プール1は2つの接続(7/3)を解放し、プール2は3つの接続(8/3)を解放します。この場合、プール・サイズの小数は切り上げられます。

クリーンアップ・モニターは、接続済リソースの数が指定の制限値を下回るまでアプリケーション・モジュールを切断する最大限の努力をしますが、使用可能な状態でアプリケーション・モジュールが十分にない場合、それを実行できないことに注意してください。JDBC接続が効率的に解放されるようにするために、「プール・ポーリング間隔」のパラメータjbo.ampool.monitorsleepintervalを構成してモニターのスリープ時間を短縮できます。

データベースの状態の初期化とプーリングに関する考慮事項

Fusion Webアプリケーションではユーザーごとにデータベース状態を設定できます。ストアド・プロシージャをコールして、特定のユーザーのセッションに関連するデータベース状態を初期化することが必要な場合があるため、これには大きなメリットがあります。

現在のユーザー・セッションに関連するデータベース状態を初期化するために、ストアド・プロシージャの起動が必要な場合もあります。その初期化を実行するには、アプリケーション・モジュールのprepareSession()メソッドをオーバーライドして行うのが正しい方法です。

ユーザー単位でのデータベース状態の設定方法

Fusion Webアプリケーションでは、ユーザーごとにデータベース状態を設定できます。通常は、データベースCONTEXTネームスペースを作成し、PL/SQLプロシージャをそれに関連付け、SYS_CONTEXT() SQL関数を使用してコンテキストから値を参照します。

たとえば、次の例に示すように、PL/SQLパッケージを使用して、現在認証されているFusion Webアプリケーション・ユーザーの名前を保持する変数をパッケージ・レベルで設定および取得できます。

create or replace package context_pkg as
  procedure set_app_user_name(username varchar2);
  function app_user_name return varchar2;
end context_pkg;

その後、このアプリケーションはビュー・オブジェクトのWHERE句を定義し、context_pkg.app_user_name関数を参照して、ユーザーごとに状態を問い合せることができます。

データベース状態を設定するには、「IN引数のみのストアド・プロシージャの呼出し方法」に示したものによく似たcallStoredProcedure()ヘルパー・メソッドをアプリケーション・モジュール・フレームワーク拡張クラス(AppModuleImpl.java)に定義します。その後、カスタム・アプリケーション・モジュール・クラスは、このフレームワーク拡張クラスを拡張し、次の例に示すsetCurrentUserInPLSQLPackage()ヘルパー・メソッドを定義します。このヘルパー・メソッドはcallStoredProcedure()メソッドを使用して、context_pkg.set_app_user_name()ストアド・プロシージャを呼び出し、パラメータ値として、現在認証されているユーザーの値を渡します。

// In CustomAppModuleImpl.java
public void setCurrentUserInPLSQLPackage() {
  String user = getUserPrincipalName();
  callStoredProcedure("context_pkg.set_app_user_name(?)",new Object[]{user});
}

このヘルパー・メソッドを使用し、カスタム・アプリケーション・モジュール・クラスは、次の例に示すように、prepareSession()メソッドをオーバーライドします。

// In CustomAppModuleImpl.java
  protected void prepareSession(Session session) {
    super.prepareSession(session);
    getLoggedInUser().retrieveUserInfoForAuthenticatedUser();     
    setUserIdIntoUserDataHashtable();
    setCurrentUserInPLSQLPackage();      
  }