子JVMプロセス

各Formsランタイム・プロセスがJVM内に個別にスレッドを持つため、同時実行性が実現します。JVMが同時リクエストの指定数に達すると、負荷を分散させるために子JVMを生成します。さらに、複数のJVMコントローラを持ち、それぞれに子JVMを持つことも可能です。

たとえば、複数のFormsアプリケーションで、オプションやクラスパスが異なるJVMを使用する必要があります。どのJVMコントローラとFormsアプリケーションが必要かは、Forms構成ファイル(formsweb.cfg)の名前付きセクションで指定できます。また、Formsアプリケーションの呼び出しに使用するURLのパラメータとしてこの情報を渡すこともできます。jvmcontrollerパラメータを使用すると、特定のJVMコントローラを使用するようにフォームを構成できます。jvmcontrollerパラメータは、どのJVMコントローラを使用するかをFormsランタイム・プロセスに指示します。jvmcontrollerを起動するときに必要な各種のパラメータは、JVMコントローラの構成ファイルjvmcontrollers.cfgで指定する必要があります(「Forms構成ファイル設定」を参照)。

次の図は、JVMプーリングを使用した場合の環境の例を示しています。2つのJVMコントローラがあり、1つはインプロセスJVMのみを使用し、もう1つは3つのJVMを使用しています。

図-38 子プロセスを持つ複数のJVMコントローラ

「図-38 子プロセスを持つ複数のJVMコントローラ」の説明

図-38には示されていませんが、各JVMコントローラには、起動、停止、またはForms構成ファイル内で参照に使用される一意な名前があります。

図-38は、複数のFormsアプリケーションで異なるJVMコントローラを使用していることを概念的に示しているだけです。ただし、Formsランタイム・プロセスは、JVMコントローラと通信せず、使用可能なJVMのいずれかと直接通信します。したがって、図の最初の2つのクライアントはインプロセスJVMを使用できるだけですが、残りのクライアントには処理に使用できるJVMが3つあります。

JVMのパフォーマンスが大幅に低下した場合は、そのJVMが処理するリクエストが多すぎる可能性があります。その場合は、そのJVMコントローラで複数の子JVMを持つようにできます。子JVMは必要に応じて動的に作成されます。

JVMパラメータのmaxsessionsは、新しい子JVMが作成されるまでに1つのJVMに対して接続できるFormsランタイム・プロセスの数を指定します。子JVMが起動すると、その子JVMはJVMコントローラと同じパラメータを継承します。

JVMがmaxsessionsで指定された接続数に達すると、そのJVMは新しいFormsランタイム・プロセスからのリクエストを受け付けなくなります。新しいFormsランタイム・プロセスが初めてJavaコードを実行しようとすると、そのプロセスは使用可能なJVM (maxsessionsより少ない接続数のもの)に接続されます。

JVMがmaxsessionsで指定された接続数に達しても、別のJVMがそれに達していなければ、新しいJVMは作成されません。すべてのJVMが同時にmaxsessionsで指定された接続数に達した場合は、別の子JVMが作成されます。

子JVMの有効範囲は、JVMコントローラのネームスペースのコンテキスト内に限定されます。たとえば、2つのJVMコントローラ、ordersJVMおよびhrJVMがある場合、ordersJVMとその子JVMは、hrJVMやその子JVMに影響を与えることはなく、これらから影響を受けることもありません。

子JVMの例

ordersJVMというJVMコントローラがmaxsessions=50に設定されているとします。実行中の各オーダー・アプリケーションは、ordersJVMにリクエストを送信します。新しいFormsランタイム・プロセスがordersJVMにリクエストを送信すると、そのたびにFormsランタイム・プロセスと通信する新しいスレッドが作成されます。その後、JVMコントローラは新しいリクエストのリスニングに戻ります。ユーザーがセッションを終了すると、JVM内のスレッドも終了します。

ordersJVMコントローラが50番目の同時リクエストを受信すると(一部のユーザーが終了した後で開始するユーザーも存在するため、最初から50番目のユーザーとはかぎりません)、コントローラは子JVMを生成します。子JVMは親の設定を継承するため、この子JVMのmaxsessionsも50になります。この段階では、JVMコントローラには50の接続があり、子JVMには接続はありません。

新しいユーザーがこのOracle Formsアプリケーションを起動し、Javaコードを実行すると、Formsランタイム・プロセスはそのJVMコントローラのネームスペース内でリスニングを実行しているJVMに接続します。このJVMコントローラには50の接続があり、使用できないため、子JVMがこのリクエストを受信します。その後、親のJVMコントローラで一部のユーザーがアプリケーションを終了し、接続数が減少すると、コントローラはmaxsessionsで指定された接続数に達しないかぎり新しいリクエストを受信することができます。

このような処理が行われる間、hrJVMはこれとは別に動作しています。ordersJVMで接続が超過してもhrJVMには接続されず、ordersJVMの子JVMに対してのみ接続が行われます。

子JVMの管理

JVMコントローラは、使用状況を監視し、必要に応じて不要なプロセスをクリーンアップまたは削除できます。これにより、貴重なサーバー・リリースの浪費を阻止し、パフォーマンスをさらに向上させることが可能になります。

デフォルトでは、このクリーンアップ機能は無効です。有効にするには、JVMコントローラ構成でパラメータautoremovalを設定します。次の表に、有効な値を示します。

表-30 子JVMの管理

値	説明
OFF (デフォルト)	自動削除機能はdisabledです。 JVMは、JVMコントローラによって自動的には削除されません。プール・サイズは増加し続け、縮小しません。子JVMは、手動で終了されるかコントローラの終了時に終了されるまで存続し続けます。
AGGRESSIVE	自動削除機能はenabledです。 子JVMを削除する頻度は最高です。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するためにM/2個のバッファ(スペア)を保持します。 この設定のメリットの1つは、現在の負荷を処理するために最小限推定される数の子JVMと、将来のリクエストに対応するために最大1つのスペアがプール内に常に存在することです。この設定のデメリットは、(セッションが頻繁に開始および停止する)アクティブな環境内でJVMの終了/作成の頻度が高くなることです。コントローラは子を管理するために過度にビジー状態になる可能性があります。 すべてのセッションがクローズされると、プール・サイズは1 (JVMコントローラ)まで縮小します。
MODERATE	自動削除機能はenabledです。 子JVMを削除する頻度はAGGRESSIVEより低くなります。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するためにM個のバッファ(スペア)を保持します。 すべてのセッションがクローズされると、プール・サイズは1 (JVMコントローラ)まで縮小します。
CONSERVATIVE	自動削除はenabledです。 子JVMを削除する頻度は前述の2つのオプションより低くなります。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するために3*M/2個のバッファを保持します。 すべてのセッションがクローズされると、プール・サイズは2 (JVMコントローラと1つの子)まで縮小します。

JVMのロード・バランシング

接続をよく編成され統一されたものにするには、ラウンド・ロビンまたは最小負荷優先(またはその両方)などの負荷分散技術をJVMコントローラに組み込むことができます。この負荷分散機能はオプションであり、JVMコントローラの構成ファイル内で構成できます。この機能を使用するには、構成ファイルでパラメータloadbalanceを設定します。これは、次のいずれかのオプションを使用して設定できます。

• 最小負荷優先

• ラウンド・ロビン

• ランダム

次の表に、有効な値を示します。

表-31 JVMのロード・バランシング

値	説明
RANDOM (デフォルト)	ランダム・モードでは、JVMコントローラは以前のバージョンのように動作します。コントローラによって作成されたすべての子が新しい接続を自由に受け入れることができます。JVMが新しい接続を受け入れることができると想定されると、JVMは新しい接続を受け入れます。
LEASTLOADEDFIRST	最小負荷優先モードでは、JVMコントローラが子JVMの接続受入れ動作を監視および制御します。一度に新しい接続リクエストをリッスンできるのは1つの子JVMのみです。JVMコントローラは、子JVMをスケジュールするために、プール内のすべての子JVMを反復し、処理対象のセッション数が最も少ない子JVMを選択します。選択した子JVMには、次の接続リクエストをリッスンするよう指示します。スケジュールされた子JVMは、セッション・リクエストを受け入れたら、確認応答をJVMコントローラに送信します。JVMコントローラは負荷分散シーケンスを開始し、プール内で次に負荷の小さい子JVMを探します。
ROUNDROBIN	ラウンド・ロビン・モードでは、JVMコントローラが子JVMの接続受入れ動作を監視および制御します。コントローラは、負荷を分散するために、JVMのリストを反復し、新しい接続リクエストを受け入れる公平な機会を各JVMに与えます。最初に、リスト内の先頭のJVMから始め、接続リクエストの受入れを開始するよう指示します。JVMコントローラは、現在スケジュールされている子JVMからの確認応答を受信し、次に使用可能な子に移動し、負荷分散シーケンスを開始します。コントローラは、使用可能なJVMをすべて繰り返します。