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

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

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

41.1項「アプリケーション・モジュール・プーリングの概要」
41.2項「プール構成パラメータの設定」
41.3項「データベースの状態の初期化とプーリングに関する考慮事項」

41.1 アプリケーション・モジュール・プーリングの概要

アプリケーション・モジュール・プールは、同じタイプのコレクション・アプリケーション・モジュール・インスタンスです。たとえば、Fusion Order Demoアプリケーションは、その中にアプリケーション・モジュールのインスタンスを1つ以上持ちます。その数は、サイトにアクセスするユーザー数に基づいて決定されます。このアプリケーション・モジュール・インスタンスのプールは、複数のブラウザ・クライアントで共有されます。これらのクライアントの標準的な「思考時間」(Webページを送信する間隔)により、アプリケーション・モジュール・コンポーネントの数がシステムで作業しているアクティブ・ユーザーの総数よりも効果的に小さくなるように最適化されます。つまり、20人のユーザーがそれぞれのブラウザーからWebサイトにアクセスしている場合、これらのユーザーと同数のアプリケーション・モジュール・インスタンスではなく、5個または10個のアプリケーション・モジュール・インスタンスでサービスを提供できる可能性があります。

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

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

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

アプリケーション・モジュール・プールの構成パラメータおよびそれがプールの動作に与える影響については、41.2.5項「構成プロパティのスコープに関する注意事項」を参照してください。

41.1.1 Fusion Webアプリケーション実行時に作成されるプールのタイプ

一般的なFusion Webアプリケーション、アプリケーション・モジュール・プールおよびデータベース接続プールの実行時に使用されるプールは、2種類あります。ユーザー・アプリケーションで各種のプールをいくつ作成するのかを理解することが重要です。

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

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

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

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

基本的には、各Java VMのFusion Webアプリケーションにより使用されるルート・アプリケーション・モジュール1つにつき、アプリケーション・モジュール・プールが1つ作成されます。これらのJava VMでは、そのタイプのルート・アプリケーション・モジュールがADFコントロール・レイヤーにより使用されます。

41.1.1.2 データベース接続プール

Fusion Webアプリケーションにより使用されるデータベース接続プールのタイプは、アプリケーション・モジュールで構成する接続のタイプによって、次のように異なります。

JDBC URL(例: jdbc:oracle:thin:@penguin:1521:ORCL)
データソースのJNDI名(例: java:comp/env/jdbc/YourConnectionDS)

アプリケーション・モジュールの構成時にJDBC URL接続を指定する(JDBC URLとユーザー名情報をカプセル化するJDeveloper名前付き接続を選択する場合に発生)と、接続プールの管理にADFデータベース接続プールが使用されます。

JDBCデータソースのJNDI名を提供した場合、ADFデータベース接続プールは使用されず、後述のADFデータベース接続プールに関係する構成パラメータは関係なくなります。

注意:

ユーザーのJava EE WebコンテナまたはEJBコンテナ(あるいはその両方)からJNDIによってチェックされるJDBCデータソースのデータベース接続プールを構成するには、Java EEコンテナのドキュメントを参照し、プーリングに関する構成オプションとその設定方法を理解してください。

ADFデータベース接続プーリングを使用する場合、ADFコントロール・レイヤーの使用するルート・アプリケーションが<JDBCURL,Username>接続を要求している個々のJava VMにある一意の<JDBCURL,Username>ペア1つにつき、データベース接続プールを1つ作成するという基本ルールがあります。

41.1.2 アプリケーション・モジュール・プールと接続プール

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

Fusion WebアプリケーションでHRModuleおよびPayablesModuleという2つのアプリケーション・モジュールを使用する。
ユーザー・アプリケーション内で値リストをサポートするためによく使用される一連のビュー・オブジェクトがCommonLOVModuleに含まれており、HRModuleにもPayablesModuleにもよく使用されるLOVビュー・オブジェクトにアクセスするためにCommonLOVModuleのインスタンスがネストされている。
HRModuleおよびPayablesModuleは、appuserという名前の同一のJDeveloper接続定義を使用するように構成済である。
HRModuleおよびPayablesModuleの両方で、jbo.passivationstore=database(デフォルト)が構成され、また状態管理に使用されるADFの「内部接続」(jbo.server.internal_connection)がappuser接続とは異なるユーザー名をポイントする完全修飾JDBC URLの値を永続的に持つように構成されている。

41.1.2.1 Oracle Application Serverインスタンスが1つ、Oracle WebLogic Serverインスタンスが1つ、JVMが1つの場合

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

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

HRModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ
PayablesModuleルート・アプリケーション・モジュール用のアプリケーション・モジュール・プールは1つ
appuser接続用のDB接続プールは1つ
状態管理を目的とする内部接続用JDBC URLのDB接続プールは1つ

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

注意:

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

41.1.2.2 Oracle Application Serverインスタンスが複数、Oracle WebLogic Serverインスタンスが1つ、JVMが複数の場合

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

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

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

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

(1つのPayablesModuleルート・アプリケーション・モジュール)×(2つのOracle Application Serverインスタンス)×(各2つのOracle WebLogic Server JVM)
appuserのDB接続プールは4つ(4つの各JVMごとに1つ)

(1つのappuserDB接続プール)×(2つのOracle Application Serverインスタンス)×(各2つのOracle WebLogic Server JVM)
内部接続JDBC URLのDB接続プールは4つ(4つの各JVMごとに1つ)

(1つの内部接続JDBC URLのDB接続プール)×(2つのOracle Application Serverインスタンス)×(各2つのOracle WebLogic Server JVM)

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

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

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

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

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

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

パラメータの表示および設定には、図41-1に示す「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。

図41-1 Configuration Managerの「プーリングおよびスケーラビリティ」タブ

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

Configuration Managerで指定した値は、アプリケーション・モジュールのXMLコンポーネント定義を基準とする./commonサブディレクトリ内のbc4j.xcfgというXMLファイルに保存されます。同一のJavaパッケージ内の全アプリケーション・モジュールの構成はすべて、この同じファイルに保存されます。

たとえば、Fusion Order DemoアプリケーションのStoreFrontプロジェクトの.src/oracle/fodemo/storefront/store/service/commonディレクトリの中にあるbc4j.xcfgファイルを見ると、例41-1のように、そのStoreServiceAMアプリケーション・モジュール用に名前の付いた構成が3つあることがわかります。この場合、StoreServiceAMLocal構成とStoreServiceAMLocalWeb構成は、Business Component BrowserがJDBC URL接続を使用するように指定しています。JDBC接続の接続詳細は、プロジェクト・ディレクトリとの相対位置指定で./.adf/META-INFと記述されるサブディレクトリにあるconnections.xmlファイルにあります。3つめのStoreFrontService構成はJDBCデータソース名を指定するもので、Fusion Webアプリケーションで使用されます。このタイプの構成は、概要エディタの「サービス・インタフェース」ページでアプリケーション・モジュールのサービス・インタフェースを公開したときに、デフォルトで生成されます。

例41-1 StoreServiceアプリケーション・モジュール用の構成

<BC4JConfig version="11.1" xmlns="http://xmlns.oracle.com/bc4j/configuration">
   <AppModuleConfigBag ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
      <AppModuleConfig 
             DeployPlatform="LOCAL" 
             JDBCName="FOD" 
             jbo.project="StoreFrontService"
             name="StoreServiceAMLocal"
             ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
         <Database jbo.locking.mode="optimistic"/>
         <Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
      </AppModuleConfig>
      <AppModuleConfig 
               DeployPlatform="LOCAL" 
               JDBCName="FOD"
               jbo.project="StoreFrontService" 
               name="StoreServiceAMLocalWeb" 
               ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM">
         <AM-Pooling jbo.ampool.initpoolsize="1"/>
         <Database jbo.locking.mode="optimistic"/>
         <Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
         <Custom fod.application.issoaenabled="true"/>
      </AppModuleConfig>
      <AppModuleConfig 
               name="StoreFrontService"
               ApplicationName="oracle.fodemo.storefront.store.service.StoreServiceAM"
               jbo.project="StoreFrontService"
               DeployPlatform="SI">
         <AM-Pooling jbo.ampool.resetnontransactionalstate="true"/>
         <Database jbo.SQLBuilder="ORACLE" jbo.locking.mode="optimistic"
                   jbo.TypeMapEntries="Java"/>
         <Security AppModuleJndiName="oracle.fodemo.storefront.store.service.StoreServiceAM"/>
         <Custom JDBCDataSource="java:comp/env/jdbc/FODDS"/>
      </AppModuleConfig>
   </AppModuleConfigBag>
</BC4JConfig>

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

41.2.3 構成パラメータをシステム・パラメータとして設定する方法

構成プロパティは、bc4j.xcfgファイルで指定するのみでなく、同じプロパティ名を持つJava VMシステム・パラメータとして設定することもできます。これらのシステム・パラメータは、問題のアプリケーション・モジュールに関連するbc4j.xcfgファイルに対応するプロパティが存在しない場合のみ使用されます。つまり、アプリケーション・モジュール構成内の構成パラメータは、Javaシステム・パラメータとして指定した同名のパラメータより優先されます。

通常、Javaシステム・パラメータは、次のようにJava VMに対するコマンドライン・フラグ-Dを使用して設定します。

java -Dproperty=value -jar yourserver.jar

また、Java EEコンテナの場合はその独自の構成ファイルの中にセクションがあり、そこではJava EEコンテナの起動時に使用されるJavaシステム・パラメータを指定できます。

システム・パラメータとして、Oracle Application Development Framework(Oracle ADF)構成パラメータにサイト固有のデフォルト値を指定する方法を使用する場合、これらのグローバルなデフォルト値にアプリケーション・モジュール固有の例外を定義するのではない限り、アプリケーションのbc4j.xcfgファイルに、これらのパラメータへの参照が含まれないことを確認する必要があります。

注意:

アプリケーション・プールおよびデータベース接続プールの両方の「アイドル・インスタンス・タイムアウト」および「プール・ポーリング間隔」の設定値は、ダイアログでは秒数として表示および編集されますが、構成ファイルにはミリ秒単位で保存されます。これら4つのパラメータの値をJavaシステム・パラメータとして指定する場合や、bc4j.xcfgファイルを手作業で編集する場合は、それらの時間間隔値をミリ秒の単位で指定してください。

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

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

例41-2 カスタムなEnvInfoProviderを使用した環境プロパティの設定

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ベース・アプリケーションで使用するには、例41-3で示すように、セッションCookieファクトリのカスタム・クラスを実装する必要があります。カスタムなセッションCookieファクトリを使用するには、構成プロパティjbo.ampool.sessioncookiefactoryclassに、セッションCookieファクトリのカスタム・クラスの完全修飾名を設定します。

例41-3 カスタムなEnvInfoProviderをインストールするためのカスタムなSessionCookieFactory

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;
  }
}

41.2.5 構成プロパティのスコープに関する注意事項

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

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

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

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

---------------------------------------------------------------
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 Business Componentsの組込み診断機能に固有なものです。

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

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

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

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

41.2.6 データベースとアプリケーション・モジュール・プールの連携に関する注意事項

ADFアプリケーション・モジュール・プールがデータベース接続プールを使用する方法は、アプリケーション・モジュール構成パラメータjbo.doconnectionpoolingの設定によって異なります。図41-1のConfiguration Managerのパネルでは、「解放時にアプリケーション・モジュールを切断(接続プーリングを使用)」チェック・ボックスを使用してこのパラメータを設定します。

注意:

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

jbo.doconnectionpooling=falseのデフォルト設定を使用した場合、任意のプールでアプリケーション・モジュール・インスタンスが作成されると、適切な接続プールから(ADFの場合はJDBC URLに基づいて、JNDIデータソース名の場合は基礎となるJDBCデータソース実装のプールから)JDBC接続が取得されます。このアプリケーション・モジュール・インスタンスは、アプリケーション・モジュール・プールから削除されるまで、プールから取得したJDBC接続オブジェクトをしっかりと維持し続けます。このアプリケーション・モジュール・インスタンスは存続期間中、多数の様々なユーザーにサービスを提供しますが、ADFがデータベース接続でのロールバックの発行に注意しているため、様々なユーザーが保留中のデータベース状態を混同してしまうことはありません。JDBC接続を確保することにより、複数のクライアントによるその後のアクセスの間、各アプリケーション・モジュール・インスタンスはJDBC PreparedStatementオブジェクトを開き、使用可能な状態を保ち続けることができるため、最高のパフォーマンスが得られます。

jbo.doconnectionpooling=trueの場合は、ユーザー・セッションがアプリケーション・モジュールの使用を終える(通常は各HTTPリクエストの終了時)たびに、アプリケーション・モジュール・インスタンスが該当するリクエストで使用していたJDBC接続を切断し、そのJDBC接続をJDBC接続プールに戻します。該当するアプリケーション・モジュール・インスタンスは、ユーザー・セッションによって次回使用されるとき、JDBC接続プールからJDBC接続を再度取得し、該当するアプリケーション・モジュールがアプリケーション・モジュール・プールからチェックアウトされている期間(この場合も、通常は1つのHTTPリクエストの期間)、そのJDBC接続を使用します。アプリケーション・モジュール・インスタンスは、PreparedStatement(現在のHTTPリクエストに対するサービスの提供時に使用された可能性がある)の作成に使用したJDBC接続オブジェクトから自分自身を切断するので、それらのPreparedStatementは次のHTTPリクエストで使用することができません(PreparedStatementは、自身が作成された接続オブジェクトのコンテキスト内でのみ有効であるため)。そのため、今の場合のように接続プーリング・モードを有効にして使用する場合は、データベース接続の総数が少なくなるかわりに、JDBCを毎回セットアップするオーバーヘッドが少し増えます。

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

50個の異なるアプリケーション・モジュール・プールがそれぞれアプリケーション・モジュール・インスタンスを内部に1つのみ持つ場合、jbo.doconnectionpooling=falseという条件では、50個のJDBCアプリケーション接続が使用されます。jbo.ampool.minavailablesize=0と設定し、適切なインスタンス・アイドル・タイムアウトが経過した後にアプリケーション・モジュール・プールを0インスタンスまで減らせるようにアプリケーション・モジュール・プーリングのパラメータを設定すると、アプリケーション・モジュールは保持していた接続をそのプールから削除されるときに元に戻します。
対照的に、50個の異なるアプリケーション・モジュール・プールがそれぞれ1つのアプリケーション・モジュール・インスタンスを持ち、jbo.doconnectionpooling=trueであった場合、使用中のJDBC接続の数は、これらのアプリケーション・モジュールのうち、異なるクライアントにより同時に使用されているものの数によって変わります。アプリケーション・モジュール・インスタンスは、プール内にあってユーザー・セッションにより使用されていない場合、jbo.doconnectionpooling=trueという条件があるため、そのJDBC接続を接続プールに解放します。そのアプリケーション・モジュール・インスタンスは、別のユーザーによって再度必要とされるかアプリケーション・モジュール・プール・モニターによって最終的にクリーンアップされるまでプール内で待機している間、JDBC接続には接続されていません。

パフォーマンスに関するヒント:

スケーラビリティと信頼性を犠牲にせず、高パフォーマンスを実現するため、jbo.doconnectionpooling構成パラメータをfalseに設定されたままにしておくことをお薦めします。それでも、データベース接続プーリングは、アプリケーション・モジュール・プーリングを介して実現されます。唯一の例外は、複数のアプリケーション・モジュール・プール(したがって、多数のアプリケーションモジュール・インスタンス)が同一のデータベースを共有する場合で、利用できるデータベース接続の総数を最優先します。

最高のパフォーマンスを得るには、アプリケーション・モジュール・プールにチェックインするたびに、データベース接続からアプリケーション・モジュール・インスタンスを接続しないでください。したがって、jbo.doconnectionpooling構成パラメータのデフォルト設定はfalseです。アプリケーション・モジュール・インスタンスのプーリングは、以前から、リソース使用率の最適化には効果的な方法でした。しかし、プールにリリースするたびに、関連するJDBC接続からアプリケーション・モジュール・インスタンスを切断する必要がない場合には、Oracle ADFランタイムがさらに効率的です。事実上、JDBC接続と1対1の関係を持つアプリケーション・モジュールをプーリングすることで、大半のFusion Webアプリケーションに最適なデータベース接続のプールはできあがっています。

しかし、データベースセッションの総数の最小化が最優先されるとき、アプリケーション・モジュール・プールの数が多く、それらのすべてにおいて基礎となる同一のアプリケーション・ユーザーのデータベース接続をデータベース・レベルで使用する必要がある場合は、データベース接続プーリングの使用が適していることがあります。この場合、多数のアプリケーション・モジュール・プールでは、それぞれ効率のロスはあるものの、JDBC接続の基礎となる同一のデータベース接続プールを共有することにより、データベース・セッションの総数を節約できます。ただし、これが有効なのは、すべてのデータベース・セッションの優先度が最大の場合のみです。このシナリオで、ユーザーがビュー・オブジェクトの行セットの、すべてではないいくつかの行をスクロールする場合に、jbo.doconnectionpooling=trueにすると、Oracle ADFは、アプリケーション・モジュールが次回使用されるときに、問い合せられたビュー・オブジェクトを、同じ最初の行がフェッチされた状態で同じ現在行に戻すことができるように、保留中のアプリケーション・モジュール状態(現在行情報を含む)を自動的に受動化します。この受動化動作はパフォーマンス低下を招くことがあります。

41.2.7 アプリケーション・モジュール・プールのパラメータに関する注意事項

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

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

アプリケーション・モジュール・プールの動作に影響を与えるアプリケーション・モジュール構成パラメータを表41-1に示します。

表41-1 プールの動作に関するアプリケーション・モジュール構成パラメータ

プール構成パラメータ説明

プール構成パラメータ	説明
管理された解放時にトランザクションの状態をフェイルオーバー (`jbo.dofailover`)	アプリケーション・モジュールが「状態管理」モードでプールに解放されるたびに、保留中のトランザクション状態の積極的な受動化が有効になります。詳細は、40.2.2.2項「オプションのフェイルオーバー・モードを有効にしたときの受動化の変化」を参照してください。 Fusion Webアプリケーションは、フェイルオーバーを使用可能に設定し(`true`)、他のアプリケーション・モジュールがいつでも状態を能動化できるようにすることをお薦めします。デフォルトでは、フェイルオーバー機能は無効になっています(`jbo.dofailover=false`)。これは、構成されているWebサーバー・インスタンスが1つのみのときに、受動化と能動化の必要性を削減することにより、パフォーマンスを最適化するためです。これにより、特定のユーザー・セッションに対するアプリケーション・モジュールのアフィニティが実現されます。可用性を高めるには、フェイルオーバー機能を有効化(`jbo.dofailover=true`)し、より多くのアプリケーション・モジュールがいつでも使用できるようにして、スケーラビリティを高めます。このモードでは、リクエストが終了するたびに、受動化が発生します。フェイルオーバーが有効化されている場合、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、`SQLException`(接続は既に閉じられている)が生成され、サーバー・ログに保存されます。確実に状態の受動化が発生し、ユーザーの変更内容が保存されるようにするには、サーバー管理者は、`weblogic-application.xml`デプロイメント・ディスクリプタの`<connection-check-params>` pool-params要素にあるパラメータ`inactive-connection-timeout-seconds`に適切な値を設定する必要があります。ほとんどの場合、デプロイメント・ディスクリプタ・パラメータを数分に設定すると、非アクティブ時の接続タイムアウトおよびその結果発生する受動化の失敗の強制が回避されます。ご使用の環境に合わせて、この設定値を調整してください。
解放時の行レベル・ロックの動作 (`jbo.locking.mode`)	アプリケーション・モジュールがプールに解放されるたびに、アプリケーション・モジュール・プールが、行レベル・ロックを使用しているデータベース上にトランザクション保留中の状態を作らないように強制します。詳細は、40.11.1項「アプリケーションを設定してオプティミスティック・ロックを使用する方法」を参照してください。 Fusion Webアプリケーションでは、ロック・モードをデフォルト値の`optimistic`のままにして、行レベル・ロックが作成されることを回避してください。このプロパティが`pessimistic`に設定されている場合、この機能は無効です。
解放時にアプリケーション・モジュールを切断(接続プーリングを使用) (`jbo.doconnectionpooling`)	アプリケーション・モジュールがプールに解放されるたびに、アプリケーション・モジュール・プールは使用中のJDBC接続を解放するように強制されます。詳細は、41.2.6項「データベースとアプリケーション・モジュール・プールの連携に関する注意事項」を参照してください。この機能はデフォルトでは無効(`false`)です。
リリース時のトランザクション・メモリの状態 (`jbo.txn.disconnect_level`)	デフォルトでは、アプリケーション・モジュールの受動化後、ビュー・オブジェクトとその行セットが閉じられ、移動されて、能動化されたときに再作成され、オリジナルの状態に戻されます。この動作は、デフォルトの`jbo.txn.disconnect_level=0`に対応します。 `jbo.txn.disconnect_level=1`と設定すると、アプリケーション・モジュール、ビュー・オブジェクト、および行セットはすべてメモリに残り、有効なままになりますが、これらに対応するJDBCオブジェクトへの参照はドロップされます。能動化にあたり、このフレームワークがカーソル位置を再実行し、同期します。 `jbo.txn.disconnect_level=1`と設定することにより、アプリケーション・モジュールがJDBC接続から切断できるようにしたときのパフォーマンスが向上し(`jbo.doconnectionpooling=true`とともに使用した場合)、この状況に関連するメモリのオーバーヘッドが軽減されます。
アプリケーション・モジュール・プーリングを使用可能にする (`jbo.ampool.doampooling`)	デフォルトでアプリケーション・モジュール・プーリングが有効になります。本番環境でアプリケーションをデプロイする場合は、常に`jbo.ampool.doampooling`をデフォルトの`true`に設定してアプリケーションを実行します。ただし、テスト環境でアプリケーションを実行するかぎり、テストでは、このプロパティを`false`に設定することで重要な役割を果せます。このプロパティが`false`の場合、実質的にアプリケーション・プールはありません。詳細は、40.10項「アプリケーション・モジュールの能動化が安全であることの確認テスト」を参照してください。この機能はデフォルトでは有効(`true`)です。
動的JDBC資格証明をサポート (`jbo.ampool.dynamicjdbccredentials`)	該当するアプリケーション・モジュールの使用を新しいユーザー・セッションが開始するたびに、データベース資格証明(ユーザー名/パスワード)の変更を開発者作成コードに許可する別のプーリング・ライフサイクル・イベントが有効になります。この機能はデフォルトで有効化(`true`)されていますが、この機能を実装するには、この設定は必要ではありますが、十分ではない条件です。機能を実装するための十分な条件が必要で、追加の開発者作成のコードが必要となります。
管理されていない解放時に非トランザクション状態をリセット (`jbo.ampool.resetnontransactionalstate)`)	アプリケーション・モジュールが非管理モード、すなわち「ステートレス」モードでプールに解放されたとき、ビュー・オブジェクトの実行時設定、JDBCプリコンパイル文、バインド変数値のような非トランザクション状態をすべてリセットするように強制します。この機能はデフォルトでは有効(`true`)です。この機能を無効化すると、パフォーマンスが向上しますが、バインド変数値がクリアされないため、ユーザーのアプリケーションでバインド変数値を正確に設定する必要があります。この機能を無効化して、ユーザーのバインド変数値のデータを別のユーザーが参照していると、障害が発生します。

管理された解放時にトランザクションの状態をフェイルオーバー

(jbo.dofailover)

アプリケーション・モジュールが「状態管理」モードでプールに解放されるたびに、保留中のトランザクション状態の積極的な受動化が有効になります。詳細は、40.2.2.2項「オプションのフェイルオーバー・モードを有効にしたときの受動化の変化」を参照してください。

Fusion Webアプリケーションは、フェイルオーバーを使用可能に設定し(true)、他のアプリケーション・モジュールがいつでも状態を能動化できるようにすることをお薦めします。

デフォルトでは、フェイルオーバー機能は無効になっています(jbo.dofailover=false)。これは、構成されているWebサーバー・インスタンスが1つのみのときに、受動化と能動化の必要性を削減することにより、パフォーマンスを最適化するためです。これにより、特定のユーザー・セッションに対するアプリケーション・モジュールのアフィニティが実現されます。

可用性を高めるには、フェイルオーバー機能を有効化(jbo.dofailover=true)し、より多くのアプリケーション・モジュールがいつでも使用できるようにして、スケーラビリティを高めます。このモードでは、リクエストが終了するたびに、受動化が発生します。

フェイルオーバーが有効化されている場合、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、SQLException(接続は既に閉じられている)が生成され、サーバー・ログに保存されます。確実に状態の受動化が発生し、ユーザーの変更内容が保存されるようにするには、サーバー管理者は、weblogic-application.xmlデプロイメント・ディスクリプタの<connection-check-params> pool-params要素にあるパラメータinactive-connection-timeout-secondsに適切な値を設定する必要があります。ほとんどの場合、デプロイメント・ディスクリプタ・パラメータを数分に設定すると、非アクティブ時の接続タイムアウトおよびその結果発生する受動化の失敗の強制が回避されます。ご使用の環境に合わせて、この設定値を調整してください。

解放時の行レベル・ロックの動作

(jbo.locking.mode)

アプリケーション・モジュールがプールに解放されるたびに、アプリケーション・モジュール・プールが、行レベル・ロックを使用しているデータベース上にトランザクション保留中の状態を作らないように強制します。詳細は、40.11.1項「アプリケーションを設定してオプティミスティック・ロックを使用する方法」を参照してください。

Fusion Webアプリケーションでは、ロック・モードをデフォルト値のoptimisticのままにして、行レベル・ロックが作成されることを回避してください。

このプロパティがpessimisticに設定されている場合、この機能は無効です。

解放時にアプリケーション・モジュールを切断(接続プーリングを使用)

(jbo.doconnectionpooling)

アプリケーション・モジュールがプールに解放されるたびに、アプリケーション・モジュール・プールは使用中のJDBC接続を解放するように強制されます。詳細は、41.2.6項「データベースとアプリケーション・モジュール・プールの連携に関する注意事項」を参照してください。

この機能はデフォルトでは無効(false)です。

リリース時のトランザクション・メモリの状態

(jbo.txn.disconnect_level)

デフォルトでは、アプリケーション・モジュールの受動化後、ビュー・オブジェクトとその行セットが閉じられ、移動されて、能動化されたときに再作成され、オリジナルの状態に戻されます。この動作は、デフォルトのjbo.txn.disconnect_level=0に対応します。

jbo.txn.disconnect_level=1と設定すると、アプリケーション・モジュール、ビュー・オブジェクト、および行セットはすべてメモリに残り、有効なままになりますが、これらに対応するJDBCオブジェクトへの参照はドロップされます。能動化にあたり、このフレームワークがカーソル位置を再実行し、同期します。

jbo.txn.disconnect_level=1と設定することにより、アプリケーション・モジュールがJDBC接続から切断できるようにしたときのパフォーマンスが向上し(jbo.doconnectionpooling=trueとともに使用した場合)、この状況に関連するメモリのオーバーヘッドが軽減されます。

アプリケーション・モジュール・プーリングを使用可能にする

(jbo.ampool.doampooling)

デフォルトでアプリケーション・モジュール・プーリングが有効になります。本番環境でアプリケーションをデプロイする場合は、常にjbo.ampool.doampoolingをデフォルトのtrueに設定してアプリケーションを実行します。ただし、テスト環境でアプリケーションを実行するかぎり、テストでは、このプロパティをfalseに設定することで重要な役割を果せます。このプロパティがfalseの場合、実質的にアプリケーション・プールはありません。詳細は、40.10項「アプリケーション・モジュールの能動化が安全であることの確認テスト」を参照してください。

この機能はデフォルトでは有効(true)です。

動的JDBC資格証明をサポート

(jbo.ampool.dynamicjdbccredentials)

該当するアプリケーション・モジュールの使用を新しいユーザー・セッションが開始するたびに、データベース資格証明(ユーザー名/パスワード)の変更を開発者作成コードに許可する別のプーリング・ライフサイクル・イベントが有効になります。

この機能はデフォルトで有効化(true)されていますが、この機能を実装するには、この設定は必要ではありますが、十分ではない条件です。機能を実装するための十分な条件が必要で、追加の開発者作成のコードが必要となります。

管理されていない解放時に非トランザクション状態をリセット

(jbo.ampool.resetnontransactionalstate))

アプリケーション・モジュールが非管理モード、すなわち「ステートレス」モードでプールに解放されたとき、ビュー・オブジェクトの実行時設定、JDBCプリコンパイル文、バインド変数値のような非トランザクション状態をすべてリセットするように強制します。

この機能はデフォルトでは有効(true)です。この機能を無効化すると、パフォーマンスが向上しますが、バインド変数値がクリアされないため、ユーザーのアプリケーションでバインド変数値を正確に設定する必要があります。この機能を無効化して、ユーザーのバインド変数値のデータを別のユーザーが参照していると、障害が発生します。

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

アプリケーション・モジュール・プールのサイズ設定に影響を与えるアプリケーション・モジュール構成パラメータを表41-2に示します。

表41-2 プールのサイズ指定に関するアプリケーション・モジュール構成パラメータ

プール構成パラメータ説明

プール構成パラメータ	説明
プールの初期サイズ (`jbo.ampool.initpoolsize`)	プールの初期化時に作成されるアプリケーション・モジュール・インスタンスの数。デフォルト値は、`0`(ゼロ)です。一般的なガイドラインは、すべてのユーザーにサービスを提供するために必要な同時アプリケーション・モジュール・インスタンス数の予想値より、10%大きな値に構成することです。追加のアプリケーション・モジュール・インスタンスが必要になったときにオンデマンドでアプリケーション・モジュール・インスタンスを作成するのでなく、初期化時に作成する場合、アプリケーション・モジュール・インスタンスを初期化時に作成するCPU処理コストが必要になります。
最大プール・サイズ (`jbo.ampool.maxpoolsize`)	プールで割り当てることができるアプリケーション・モジュール・インスタンスの最大数。プールでは、この限界値を超える数のアプリケーション・モジュール・インスタンスを作成しません。デフォルト値は、`4096`(インスタンス)です。一般的なガイドラインは、初期プール・サイズより20%大きく構成し、後から必要になる拡張に備えることです。低すぎる値に設定すると、利用できるアプリケーション・モジュール・インスタンスがない場合にアプリケーションにアクセスした一部のユーザーに対してエラーが発生します。
参照プール・サイズ (`jbo.recyclethreshold`)	状態管理モードでアプリケーション・モジュール・インスタンスをプールに解放する直前にそれらのアプリケーション・モジュール・インスタンスを使用していたセッションによる次のリクエストのためにセッション・アフィニティを維持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数。このパラメータ値は常に、「最大プール・サイズ」の値以下である必要があります。デフォルトでは`10`個のインスタンスが、状態管理モードでそれらのインスタンスを解放した直近のセッションとのアフィニティに従うことができます。この値は、ユーザーのセッションへのアプリケーション・モジュール・インスタンスのアフィニティを維持するように構成します。一般的なガイドラインは、短い思考時間で複数の操作を行う同時ユーザー数の予想値に構成することです。短い思考時間でアプリケーションを使用すると予想されるユーザーがいない場合、これを`0`(ゼロ)に構成してアフィニティを除去できます。このアフィニティを可能なかぎり大きく構成すると、ユーザー・セッションからユーザー・セッションにアプリケーション・モジュール・インスタンスを切り替える必要がなくなるため、CPU処理コストを節減できます。
インスタンスの最大有効時間 (`jbo.ampool.timetolive`)	この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内のアプリケーション・モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。デフォルト値は3600000ミリ秒(3600秒または1時間)です。大部分のアプリケーションには、デフォルト値で十分です。

プールの初期サイズ

(jbo.ampool.initpoolsize)

プールの初期化時に作成されるアプリケーション・モジュール・インスタンスの数。

デフォルト値は、0(ゼロ)です。一般的なガイドラインは、すべてのユーザーにサービスを提供するために必要な同時アプリケーション・モジュール・インスタンス数の予想値より、10%大きな値に構成することです。

追加のアプリケーション・モジュール・インスタンスが必要になったときにオンデマンドでアプリケーション・モジュール・インスタンスを作成するのでなく、初期化時に作成する場合、アプリケーション・モジュール・インスタンスを初期化時に作成するCPU処理コストが必要になります。

最大プール・サイズ

(jbo.ampool.maxpoolsize)

プールで割り当てることができるアプリケーション・モジュール・インスタンスの最大数。プールでは、この限界値を超える数のアプリケーション・モジュール・インスタンスを作成しません。

デフォルト値は、4096(インスタンス)です。一般的なガイドラインは、初期プール・サイズより20%大きく構成し、後から必要になる拡張に備えることです。低すぎる値に設定すると、利用できるアプリケーション・モジュール・インスタンスがない場合にアプリケーションにアクセスした一部のユーザーに対してエラーが発生します。

参照プール・サイズ

(jbo.recyclethreshold)

状態管理モードでアプリケーション・モジュール・インスタンスをプールに解放する直前にそれらのアプリケーション・モジュール・インスタンスを使用していたセッションによる次のリクエストのためにセッション・アフィニティを維持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数。

このパラメータ値は常に、「最大プール・サイズ」の値以下である必要があります。デフォルトでは10個のインスタンスが、状態管理モードでそれらのインスタンスを解放した直近のセッションとのアフィニティに従うことができます。

この値は、ユーザーのセッションへのアプリケーション・モジュール・インスタンスのアフィニティを維持するように構成します。一般的なガイドラインは、短い思考時間で複数の操作を行う同時ユーザー数の予想値に構成することです。短い思考時間でアプリケーションを使用すると予想されるユーザーがいない場合、これを0(ゼロ)に構成してアフィニティを除去できます。

このアフィニティを可能なかぎり大きく構成すると、ユーザー・セッションからユーザー・セッションにアプリケーション・モジュール・インスタンスを切り替える必要がなくなるため、CPU処理コストを節減できます。

インスタンスの最大有効時間

(jbo.ampool.timetolive)

この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内のアプリケーション・モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は3600000ミリ秒(3600秒または1時間)です。大部分のアプリケーションには、デフォルト値で十分です。

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

Java VMごとに1つのアプリケーション・モジュール・プール・モニターがバックグラウンド・スレッドで動作し、しばしばウェイクアップしてリソースの再生を実行します。プール・モニターが各リソース・クリーンアップ・パスを実行するときのリソースの再生処理に影響を与えるパラメータを、表41-3に示します。

ベスト・プラクティス:

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

表41-3 リソースの管理に関するアプリケーション・モジュール構成パラメータ

プール構成パラメータ説明

プール構成パラメータ	説明
プール・ポーリング間隔 (`jbo.ampool.monitorsleepinterval`)	プール・リソース・クリーンアップの時間間隔(ミリ秒)。プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。アプリケーション・モジュール・プール・モニターは、デフォルトでは`600000`ミリ秒(600秒または10分)ごとにウェイクアップします。短い間隔を構成すると、アクティブでないアプリケーション・モジュール・インスタンスを、メモリーを節約するために削除する頻度が高くなります。間隔を長くすると、リソース・クリーンアップの頻度が低くなります。
使用可能な最大サイズ (`jbo.ampool.maxavailablesize`)	負荷が異常でない場合に理想的な、利用できるプール内のアプリケーション・モジュール・インスタンスの最大数。プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。デフォルト値は、`25`(インスタンス)です。リソース・クリーンアップ後に利用可能にしておきたいインスタンス数の最大数に構成します。一般に、値を低くすると、クリーンアップの際にプールから削除されるアプリケーション・モジュール・インスタンスの数が増えます。
使用可能な最小サイズ (`jbo.ampool.minavailablesize`)	リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なアプリケーション・モジュール・インスタンスの最小数。リソースのクリーンアップ後にすべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、`0`(ゼロ)を設定します。デフォルト値は、`5`(インスタンス)です。
アイドル・インスタンス・タイムアウト (`jbo.ampool.maxinactiveage`)	この時間(ミリ秒)を超えると、プール内の非アクティブなアプリケーション・モジュール・インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。デフォルト値は、600000ミリ秒(600秒または10分)です。値を低くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が増えます。値を高くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が減ります。
インスタンスの最大有効時間 (`jbo.ampool.timetolive`)	この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内の接続モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。デフォルト値は3600000ミリ秒(3600秒または1時間)です。値を低くすると、次回のリソース・クリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が短くなります。大部分のアプリケーションには、デフォルト値で十分です。値を高くすると、次回のクリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が長くなります。

プール・ポーリング間隔

(jbo.ampool.monitorsleepinterval)

プール・リソース・クリーンアップの時間間隔(ミリ秒)。

プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。

アプリケーション・モジュール・プール・モニターは、デフォルトでは600000ミリ秒(600秒または10分)ごとにウェイクアップします。短い間隔を構成すると、アクティブでないアプリケーション・モジュール・インスタンスを、メモリーを節約するために削除する頻度が高くなります。間隔を長くすると、リソース・クリーンアップの頻度が低くなります。

使用可能な最大サイズ

(jbo.ampool.maxavailablesize)

負荷が異常でない場合に理想的な、利用できるプール内のアプリケーション・モジュール・インスタンスの最大数。

プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。

デフォルト値は、25(インスタンス)です。リソース・クリーンアップ後に利用可能にしておきたいインスタンス数の最大数に構成します。一般に、値を低くすると、クリーンアップの際にプールから削除されるアプリケーション・モジュール・インスタンスの数が増えます。

使用可能な最小サイズ

(jbo.ampool.minavailablesize)

リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なアプリケーション・モジュール・インスタンスの最小数。

リソースのクリーンアップ後にすべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、0(ゼロ)を設定します。

デフォルト値は、5(インスタンス)です。

アイドル・インスタンス・タイムアウト

(jbo.ampool.maxinactiveage)

この時間(ミリ秒)を超えると、プール内の非アクティブなアプリケーション・モジュール・インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は、600000ミリ秒(600秒または10分)です。値を低くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が増えます。値を高くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が減ります。

インスタンスの最大有効時間

(jbo.ampool.timetolive)

この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内の接続モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は3600000ミリ秒(3600秒または1時間)です。値を低くすると、次回のリソース・クリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が短くなります。大部分のアプリケーションには、デフォルト値で十分です。値を高くすると、次回のクリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が長くなります。

41.2.8 データソース構成に関する注意事項

アプリケーション・モジュールの接続タイプとしてJDBCデータソースを指定すると、データベース接続プールのために設定されている構成パラメータはすべて無視されます。データｿｰｽ用に接続プールを構成するには、使用しているJava EEコンテナの提供する方法を使用する必要があります。Oracle WebLogic Serverの場合、Oracle WebLogic Server管理コンソールを使用してデータソースを構成します。

JDBCデータ・ソースを構成する主な手順は次のとおりです。

接続先となる各データベースのデータ・ソースを作成します。データソースを作成するときには、表41-4で説明されているADFビジネス・コンポーネント・データベース接続プールの構成オプションと一致する構成オプションを指定します。ここで指定する構成設定は、使用しているデータベース、およびアプリケーションに見込んでおく必要のある容量計画に依存します。

JDBCデータソースの構成および接続プールの容量計画立案の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』を参照してください。
必要に応じて、データソースのトランザクション・オプションを構成します。
必要に応じて、データソースの接続テスト・オプションを構成します。
必要に応じて、データソースを追加のサーバーおよびクラスタにターゲット指定します。

これらの手順の詳細は、管理コンソール・オンライン・ヘルプにあるJDBCデータソースの構成に関するトピックを参照してください。

表41-4 同等のOracle WebLogic Serverデータソース・パラメータ

ADFビジネス・コンポーネント・パラメータ	Oracle WebLogic Serverパラメータ
プールの初期サイズ (`jbo.initpoolsize`)	初期容量
最大プール・サイズ (`jbo.maxpoolsize`)	最大容量
プール・ポーリング間隔 (`jbo.poolmonitorsleepinterval`)	Oracle WebLogic Serverには、同等なものがありません。
使用可能な最大サイズ (`jbo.poolmaxavailablesize`)	最大容量
使用可能な最小サイズ (`jbo.poolminavailablesize`)	最大容量
アイドル・インスタンス・タイムアウト (`jbo.poolmaxinactiveage`)	縮小間隔

41.2.9 データベース接続プールのパラメータに関する注意事項

接続情報としてJDBC URLを使用しADFデータベース接続プールを使用する場合は、表41-5の構成パラメータを使用すると、データベース接続プールの動作をチューニングできます。Java VMごとに1つのデータベース接続プール・モニターがバックグラウンド・スレッドで動作し、しばしばウェイクアップしてリソースの再生を実行します。プール・モニターが各リソース・クリーンアップ・パスを実行するときのリソースの再生処理に影響を与えるパラメータを、表41-3に示します。

注意:

データベース接続プーリング用の構成パラメータは、MetaObjectManagerスコープを持ちます(前述の41.2.5項「構成プロパティのスコープに関する注意事項」を参照)。つまり、それらの設定値はグローバルで、アプリケーション内で最初のアプリケーション・モジュール・プールが作成されるときに設定されます。最も予想可能な動作が確実に行われるようにするには、「プーリングおよびスケーラビリティ」タブの「接続プール」セクションにあるこれらのパラメータの値をデフォルト値のままにしておきます。こうしておくと、これらのパラメータについて、bc4j.xcfgファイルには何も書き込まれません。その代わりに、Java EEコンテナのJavaシステム・パラメータとして、データベース接続プールのチューニング・パラメータに必要な値を設定します。

表41-5 データベース接続プールのパラメータ

プール構成パラメータ説明

プール構成パラメータ	説明
プールの初期サイズ (`jbo.initpoolsize`)	プールの初期化時に作成されるJDBC接続インスタンスの数。デフォルト値は`0`(インスタンス)です。
最大プール・サイズ (`jbo.maxpoolsize`)	プールで割り当てることができるJDBC接続インスタンスの最大数。この限界値を超える数のJDBC接続がプールによって作成されることはありません。デフォルト値は、`4096`(インスタンス)です。
プール・ポーリング間隔 (`jbo.poolmonitorsleepinterval`)	プール・リソース・クリーンアップの時間間隔(ミリ秒)。プール内のJDBC接続インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、JDBC接続プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。デフォルト値は、`600000`ミリ秒(600秒または10分)です。短い間隔を構成すると、アクティブでない接続インスタンスを、メモリーを節約するために削除する頻度が高くなります。間隔を長くすると、リソース・クリーンアップの頻度が低くなります。
使用可能な最大サイズ (`jbo.poolmaxavailablesize`)	負荷が異常でない場合に理想的な、プール内のJDBC接続インスタンスの最大数。リソースのクリーンアップを実行するためにプールの監視が起動すると、使用可能なJDBC接続インスタンスを削除して、この理想の最大数にまで使用可能なインスタンスの数を下げようと試行されます。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。デフォルトの最大使用可能サイズは`25`インスタンスです(ロードが発生していない場合)。
使用可能な最小サイズ (`jbo.poolminavailablesize`)	リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なJDBC接続インスタンスの最小数。すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、ゼロ(`0`)を設定します。デフォルトでは、利用可能な最小サイズを`5`(インスタンス)未満にしません。
アイドル・インスタンス・タイムアウト (`jbo.poolmaxinactiveage`)	この時間(ミリ秒)を超えると、プール内の非アクティブなJDBC接続インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。デフォルト値は、`600000`ミリ秒(600秒または10分)です。

プールの初期サイズ

(jbo.initpoolsize)

プールの初期化時に作成されるJDBC接続インスタンスの数。

デフォルト値は0(インスタンス)です。

最大プール・サイズ

(jbo.maxpoolsize)

プールで割り当てることができるJDBC接続インスタンスの最大数。

この限界値を超える数のJDBC接続がプールによって作成されることはありません。デフォルト値は、4096(インスタンス)です。

プール・ポーリング間隔

(jbo.poolmonitorsleepinterval)

プール・リソース・クリーンアップの時間間隔(ミリ秒)。

プール内のJDBC接続インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、JDBC接続プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。

デフォルト値は、600000ミリ秒(600秒または10分)です。短い間隔を構成すると、アクティブでない接続インスタンスを、メモリーを節約するために削除する頻度が高くなります。間隔を長くすると、リソース・クリーンアップの頻度が低くなります。

使用可能な最大サイズ

(jbo.poolmaxavailablesize)

負荷が異常でない場合に理想的な、プール内のJDBC接続インスタンスの最大数。

リソースのクリーンアップを実行するためにプールの監視が起動すると、使用可能なJDBC接続インスタンスを削除して、この理想の最大数にまで使用可能なインスタンスの数を下げようと試行されます。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。デフォルトの最大使用可能サイズは25インスタンスです(ロードが発生していない場合)。

使用可能な最小サイズ

(jbo.poolminavailablesize)

リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なJDBC接続インスタンスの最小数。すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、ゼロ(0)を設定します。

デフォルトでは、利用可能な最小サイズを5(インスタンス)未満にしません。

アイドル・インスタンス・タイムアウト

(jbo.poolmaxinactiveage)

この時間(ミリ秒)を超えると、プール内の非アクティブなJDBC接続インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は、600000ミリ秒(600秒または10分)です。

ただし、データベース接続プールはセッション・アフィニティのヒューリスティックを実装しないため、このデータベース接続プールについて、参照されるプール・サイズを制御する構成パラメータはありませんので注意してください。

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

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

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

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

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

例41-4 CONTEXT_PKG PL/SQLパッケージ

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関数を参照して、ユーザーごとに状態を問合せることができます。

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

例41-5 ストアド・プロシージャ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});
}

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

例41-6 afterConnect()およびprepareSession()のオーバーライドによるデータベース状態の設定

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

41.3.2 データベース・ユーザーの状態およびjbo.doconnectionpooling = trueに関する注意事項

jbo.doconnectionpoolingのデフォルト設定はfalseです。これはアプリケーション・モジュール・インスタンスがJDBC接続をしっかりと捕捉しながら、アプリケーション・モジュール・プール内に存在することを意味します。この設定では、アプリケーション・モジュールはJDBCのプリコンパイル済SQL文をアプリケーション・モジュールのチェックアウト/チェックインの間、オープンのままにしておけるため、最も効果的です。アプリケーション・モジュール・インスタンスは、新しいユーザー・セッションがprepareSession()メソッドを使用し始めるたびに、このメソッドをトリガーします。

jbo.doconnectionpoolingをtrueに設定すると、アプリケーション・モジュールがプールからチェックアウトされるたびに、アプリケーション・モジュール・プールはデータベース接続プールからJDBC接続を取得し、現在のリクエストの期間中、それを使用します。該当リクエストの終了時、アプリケーション・モジュールがアプリケーション・モジュール・プールに解放されるとき、アプリケーション・モジュール・プールは使用していたJDBC接続をデータベース接続プールに解放します。

jbo.doconnectionpoolingがtrueに設定されているので、プール内のアプリケーション・モジュール・インスタンスはその後、プールからチェックアウトされるたびにまったく異なるJDBC接続を持つ可能性があります。この場合は、該当するアプリケーション・モジュールがプールからチェックアウトされるたびにprepareSession()メソッドが起動され、ユーザーはデータベース状態を初期化しなおすことができます。

代わりに、jbo.txn.disconnect_level=1と設定して(デフォルトは0)、対応するJDBCオブジェクトへの参照がドロップされたあとでも、アプリケーション・モジュール、ビュー・オブジェクト、および行セットをすべてメモリに残し、有効のままにすることもできます。能動化にあたり、このフレームワークがカーソル位置を再実行し、同期します。jbo.doconnectionpooling=trueとともに使用する場合、jbo.txn.disconnect_level=1と設定すると、この状況に関連するメモリのオーバーヘッドが軽減されます。