この章の構成は、次のとおりです。
Oracle Formsアプリケーションがサーバーで最初にJavaをコールしてからランタイム・プロセスが有効である間は、プロセスが再びJavaをコールしなくても、JVMはランタイム・プロセスに接続された状態で維持されます。各Formsランタイム・セッションによって独自のJVMインスタンスが作成されるとすると、サーバー上で消費されるリソースの量が膨大になる可能性があります。
JVMプーリング環境では、複数のFormsランタイム・プロセスによってJVMが共有されます。単一のJVMが、異なるランタイム・プロセスから複数のFormsセッションを処理できます。プーリング環境では、ランタイム・プロセス当たり1つのJVMを接続しなくてすむため、ホストされたマシン上のメモリーのフットプリントを大幅に削減できます。この環境は、構成可能です。Forms管理者は、様々なパラメータを設定したり、ニーズや要件に基づいて環境をチューニングできます。また、単一のJVMプロセスによって管理されるランタイム・セッションの数に対する制限を設定することもできます。
JVMプーリングを使用する場合、JVMコントローラが作成されます。これは、特定の職責を持つJVMです。ランタイム・プロセスから接続を受け入れる以外に、必要に応じて新しいJVMを作成する職責もあります。新しいJVMプロセス(子JVMとも呼ばれます)が作成されるのは、コントローラが(コントローラ自体を含む)プール内の既存のJVMがランタイム・プロセスからの追加セッションに対応できないと判断した場合のみです。
Oracle Forms JVMプーリングは、Forms Java Importerと連携して機能します。また、Oracle ReportsおよびOracle BI-PublisherをコールするFormsの機能とも連携します。Java Importerを使用すると、開発者は設計時にPL/SQLからJavaクラスを参照できます。実行時に、Javaクラスは必要に応じてJVMによってロードおよび実行されます。
Java Importerの詳細は、Oracle Form Builderのオンライン・ヘルプを参照してください。
各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を使用しています。
図10-1には示されていませんが、各JVMコントローラには、起動、停止、またはForms構成ファイル内で参照に使用される一意な名前があります。
図10-1は、複数の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の選択方法は完全に任意で、ロード・バランシングやラウンドロビン・アルゴリズムはありません。
JVMがmaxsessionsで指定された接続数に達しても、別のJVMがそれに達していなければ、新しいJVMは作成されません。すべてのJVMが同時にmaxsessionsで指定された接続数に達した場合は、別の子JVMが作成されます。
子JVMは負荷が低下しても自動的に削除されません。そのため、一部の子JVMを削除する場合は、JVMコントローラを停止する必要があります。これにより、すべての子JVMも停止します。その後、JVMコントローラを再起動できます。
子JVMの有効範囲は、JVMコントローラのネームスペースのコンテキスト内に限定されます。たとえば、2つのJVMコントローラ、ordersJVM
およびhrJVM
がある場合、ordersJVMとその子JVMは、hrJVM
やその子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に対してのみ接続が行われます。
12より前のOracle Formsバージョンでは、子JVMプロセスは親コントローラの存続期間中は存続していました。これは、ピーク時に多くの子プロセスが作成されたとしても、負荷が減少したときにこれらの子プロセスをリリースできないことを意味します。Forms 12以降では、コントローラが使用状況を監視し、必要に応じて不要なプロセスをクリーンアップまたは実行できるようになりました。これにより、貴重なサーバー・リリースの浪費を阻止し、パフォーマンスをさらに向上させることが可能になります。デフォルトでは、このクリーンアップ機能は無効です。有効にするには、JVMコントローラ構成でパラメータautoremoval
を設定します。次の表に、有効な値を示します。
表10-1 子JVMの管理
値 | 説明 |
---|---|
OFF (デフォルト) |
自動削除機能は JVMは、JVMコントローラによって自動的には削除されません。プール・サイズは増加し続け、縮小しません。子JVMは、手動で終了されるかコントローラの終了時に終了されるまで存続し続けます。 |
AGGRESSIVE |
自動削除機能は 子JVMを削除する頻度は最高です。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するためにM/2個のバッファ(スペア)を保持します。 この設定のメリットの1つは、現在の負荷を処理するために最小限推定される数の子JVMと、将来のリクエストに対応するために最大1つのスペアがプール内に常に存在することです。この設定のデメリットは、(セッションが頻繁に開始および停止する)アクティブな環境内でJVMの終了/作成の頻度が高くなることです。コントローラは子を管理するために過度にビジー状態になる可能性があります。 すべてのセッションがクローズされると、プール・サイズは1 (つまり、JVMコントローラ)まで縮小します。 |
MODERATE |
自動削除機能は 子JVMを削除する頻度はAGGRESSIVEより低くなります。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するためにM個のバッファ(スペア)を保持します。 すべてのセッションがクローズされると、プール・サイズは1 (つまり、JVMコントローラ)まで縮小します。 |
CONSERVATIVE |
自動削除は 子JVMを削除する頻度は前述の2つのオプションより低くなります。 JVMがこの構成内で最大M個のセッションに対応できると仮定すると、コントローラは将来のセッション・リクエストに対応するために3*M/2個のバッファを保持します。 すべてのセッションがクローズされると、プール・サイズは2 (つまり、コントローラと1つの子)まで縮小します。 |
接続をよく編成され統一されたものにするには、ラウンド・ロビンまたは最小負荷優先(またはその両方)などの負荷分散技術をJVMコントローラに組み込むことができます。この負荷分散機能はオプションであり、JVMコントローラの構成ファイル内で構成できます。この機能を使用するには、構成ファイルでパラメータloadbalance
を設定します。これは、次のいずれかのオプションを使用して設定できます。
最小負荷優先
ラウンド・ロビン
ランダム
次の表に、有効な値を示します。
表10-2 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をすべて繰り返します。 |
JVMプーリングのアーキテクチャでは、複数のJVMコントローラを持ち、それぞれが子JVMを持つことができます。
複数のJVMコントローラを使用するのは、次のような場合です。
アプリケーションごとにJVMコントローラを持ち、他のコントローラとは個別に起動および停止できるようにする場合。
アプリケーションごとに異なる設定が必要な場合。たとえば、複数のコントローラでクラスパスやJVMの設定を分ける場合です。
Fusion Middleware ControlからJVMコントローラのリソース使用率を監視する場合。複数のアプリケーションまたはユーザー・グループで異なるJVMコントローラが使用されている場合は、Java Importerコードによってどのようにリソースが消費されているかを確認できます。
同一コンピュータ上に複数の開発環境、テスト環境または本番環境がある場合。
複数の異なるアプリケーションで静的データを共有しない場合。
この例では、ユーザー・インタフェースのボタンを持つOracle Formsアプリケーションについて考えてみます。
ユーザーがボタンを押すと、Oracle Formsは画面上のフィールドから値を取得してJavaに渡し(Java Importer機能を使用)、PL/SQLでは実行できないなんらかの複雑な計算を実行します。その後、結果が返され、フォーム内のフィールドに表示されます。このFormsセッションを実行するために、1つのJVMプロセスが実行されています。
次の図は、JVMプーリングが有効になっていないために、このOracle Formsセッションに個別のインプロセスJVMが存在する様子を示しています。図の左側には、独自のFormsセッションを実行する複数のクライアントが示されています。図の中央で、各クライアントは、独自のJVMプロセスを含む独自のFormsランタイム・プロセスをコールします。
次の図は、JVMプーリングが有効になっている場合に、複数のFormsランタイム・プロセスで単一のJVMプロセスが共有される様子(図の右側)を示しています。
前の図に示すように、この例では、同じアプリケーションでそれぞれ独自のランタイム・プロセスを使用して機能している5つのクライアントが、独自のJVMインスタンスを生成するそれぞれのFormsランタイム・プロセスを使用するかわりに、1つのプールされたJVMプロセスを使用しています。このため、メモリー使用率とシステム・リソースを大幅に節約できます。
JVMプーリングが利用可能になる時点より前にOracle FormsのJava Importer機能を使用していた場合は、JVMプーリングを使用する前にJavaクラスを再インポートする必要があります。Javaクラスを初めてインポートしたときには、そのJavaクラスのPL/SQLラッパーが生成されています。これは、フォームで作成されたプログラム・ユニット内で確認することができます。ただし、JVMプーリングを使用するJava Importerで生成されているPL/SQLラッパーはこれとは異なります。
Oracle Forms Services 10g以降では、Java Importerは新しいPL/SQLラッパーを生成します。Java Importerを使用し、JVMプーリングを利用しない場合は、インプロセスJVMは新しい PL/SQLラッパーで正常に機能します。また、旧スタイルのPL/SQLラッパーでもこれまでどおりに機能します。
JVMプーリングのメリットの1つに、同一クラスの複数のインスタンス間で静的変数を使用してデータを共有する機能があります。ただし、静的変数は1つのJVM内の同一クラスのインスタンス間で共有され、複数のJVM間では共有されません。この条件に従って計画を立案する必要があります。
たとえば、ローン・クラスのすべてのインスタンスで同じ金利を使用して計算を実行するという理由で、interestRate
という静的変数が用意されているとします。JVMを1つのみ使用する場合は、ローン・クラスの1つのインスタンスでinterestRate
が変更されると、その他のすべてのインスタンスが影響を受けます(これは意図した動作です)。
ただし、JVMコントローラに1つ以上の子JVMが存在する場合は、2つ以上のJVMが存在する場合があります。1つのJVMでinterestRateが変更されても、他のJVMにあるローン・インスタンスでは新しい値が認識されません(「子JVMプロセス」を参照)。JVMプーリングを使用しておらず、interestRateを変更した場合は、各Oracle Formsのランタイム・プロセスが個別にインプロセスJVMを持つため、その変更により他のインスタンスは影響を受けません。
静的変数を使用してクラスの複数のインスタンス間で情報を共有する場合は、maxsessions
を65535
に設定して、子JVMが生成されないようにしてください。
Fusion Middleware Controlを使用してJVMを構成するには、一定の手順を実行する必要があります。
次の手順を実行します。
formsweb.cfg
に新しい構成セクションを追加するか、そこにある既存の構成セクションを変更し、アプリケーションでのJVMコントローラの使用を有効または無効にします。default.env
またはjvmcontrollers.cfg
でCLASSPATHが更新されていることを確認します。Forms構成ファイルで使用されるJVMプーリング・パラメータの詳細は、「Forms構成ファイル設定」を参照してください。
JVMパラメータの詳細は、「パラメータの管理」を参照してください。
JVMコントローラの詳細は、「Fusion Middleware ControlによるJVMコントローラの起動と停止」を参照してください。
JVMプーリングが有効で、JVMコントローラでJavaが実行される場合、jvmcontrollers.cfgファイルでjvmoptions
パラメータを設定することが必要な場合があります。このパラメータをユーザーが使用し、ネットワーク・プロキシに関連するJavaプロパティを設定できます。Oracle Reports、Oracle BI-Publisherをコールするか、インポートしたJavaを使用するとともに、これらのコールでネットワーク・プロキシを介してアクセスする必要があるアプリケーションの場合、適切なパラメータを使用して、使用中のプロキシに適した環境を構成します
http.proxyHost
http.proxyPort
https.proxyHost
https.proxyPort
http.nonProxyHosts
これらのプロパティの詳細は、次を参照してください
Javaドキュメントのhttps://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html
。
コマンドラインからJVMコントローラを管理するには、JVMコントローラの起動および停止のオプションを理解し、環境を指定する必要があります。
JVMコントローラを実行しているコンピュータと同じコンピュータ上にあるJVMコントローラにのみアクセスできます。
この章で説明するJVMコントローラの制御メカニズムは、主にコマンドラインに関連しています。使いやすい画面とオンライン・ヘルプのあるFusion Middleware Controlを使用する方法のほうが簡単です。ただし、各種のフィールドやオプションの意味およびJVMコントローラの動作の仕組みを理解するために、Fusion Middleware Controlのユーザーも次の情報を参照することをお薦めします。
この項では、JVMコントローラのコマンドの例について説明します。これらの例の詳しい説明は、「起動の例」を参照してください。
注意:
コマンドラインの使用を試みる前に、環境変数FORMS_INSTANCE
を設定する必要があります。
dejvm -start jvmcontroller=hrJVM
hrJVMというIDのJVMコントローラを起動します。コントローラ名hrJVMは、構成ファイルの名前付きセクションで定義されています。このため、JVMオプションとクラスパス・パラメータは構成ファイルから取得されます。maxsessions
はデフォルト・セクションでの定義に従って50
になり、他のパラメータはそれぞれのデフォルト値になります。
dejvm -start jvmcontroller=myJVM
myJVMというIDのJVMコントローラを起動します。オプションの指定がなく、jvmcontrollers.cfg
に名前付きセクションがないため、JVMオプション・パラメータは、デフォルト・セクションでの設定に従って"-Xms512m -Xmx1024m"
およびmaxsessions=50
になります。他のパラメータはそれぞれのデフォルト値になります。たとえば、CLASSPATHの値はシステムCLASSPATHです。
dejvm -start jvmcontroller=hrJVM jvmoptions="-Xms128m -Xmx256m" maxsessions=75
名前付きセクションでの定義に従って、クラスパスを/myJava/hrClasses
に設定します。コマンド・ラインはjvmcontrollers.cfg
ファイルをオーバーライドするため、JVMオプションは"-Xms128m -Xmx256m"
になります。同様に、maxsessions
は75
です。他のパラメータはすべて、それぞれのデフォルト値になります。
dejvm -start jvmcontroller=myJVM maxsessions=100 classpath=/myJava/myClasses;/moreJava/moreClasses
jvmcontrollers.cfg
のデフォルト・セクションでの定義に従って、コントローラにはjvmoptions="-Xms512m -Xmx1024m"
が設定されます。maxsessionsは100になり(デフォルト・セクションをオーバーライドする)、クラスパスは/myJava/myClasses;/moreJava/moreClasses
となります。他のパラメータはすべて、それぞれのデフォルト値になります。
dejvm -stop jvmcontroller=hrJVM
hrJVMコントローラを停止します。これは、このコマンドを正常に発行するために、起動済である必要があります。
次のコマンド制限に注意してください。
コマンドでは、大文字と小文字が区別されます。
1度に1つのコマンドのみをJVMコントローラに発行できます。
1度に1つのJVMコントローラに対してのみ、コマンドを発行できます。
JVMコントローラ(dejvmプロセス)で使用可能なコマンドを表10-3に示します。Enterprise Managerを使用している場合は、これらのコマンドを発行するためのインタフェースを含む画面があります。コマンドラインを使用している場合は、Enterprise Managerを使用したJVMコントローラの管理はできないことがあります。
次の表に、コマンドラインからJVMを起動するために使用するJVMパラメータを示します。
表10-3 JVMパラメータ
パラメータ | 説明 |
---|---|
jvmcontroller |
JVMの名前を入力します。この名前は、文字で始まり、英数字、'_'、'$'、または'#'で構成される有効なOracle識別子にする必要があります。Oracle識別子の最大長は30バイトです。 ヒント: 名前は、それにアクセスするアプリケーションの名前に基づいたものを入力することをお薦めします。このJVMコントローラの名前は後から変更できません。 |
maxsessions |
新規JVMが生成される前に該当のJVMが処理する最大同時Oracle Formsセッション数を指定します。この値は、デフォルトJVMコントローラ用のセットをオーバーライドします。 |
classpath |
クラスパスを指定すると、環境で指定されたクラスパスまたはシステムのクラスパス、またはデフォルトJVMコントローラ用のクラスパス・セットをオーバーライドします。 |
jvmoptions |
JVMに渡すために有効なオプションを入力します。この値は、デフォルトJVMコントローラ用のセットをオーバーライドします。有効なJVM起動オプションの詳細は、Oracle Javaドキュメントを参照してください。 |
logdir |
デフォルトJVMコントローラのログ・ディレクトリを使用する場合は、「ログ・ディレクトリ」を空白のままにしておきます。他のディレクトリが設定されている場合は、Enterprise Managerからログ・ファイルにアクセスできないことがあります。 |
logging |
|
Fusion Middleware Controlでは、使用可能なすべてのJVMプーリング・オプションを管理するためにWebベースの環境が用意されています。また、環境内のすべてのJVMコントローラが一覧表示され、(リモートで)これらを管理することができます。
たとえば、JVMコントローラの起動や停止、新規コントローラの追加、既存のコントローラの再構成などができます。さらに、Fusion Middleware Controlでは、JVMコントローラで消費されるリソース(メモリーやCPU)、接続されているFormsの数、JVMの総数などのメトリック情報も得られます。
Formsランタイム・プロセスが直接JVMと対話的に処理するとき、JVMコントローラではそのJVMを管理(JVMの起動や停止、JVMの状態情報の取得など)します。たとえば、管理者がJVMコントローラを停止すると、JVMコントローラではすべての子JVMを終了したことを確認します。Fusion Middleware Controlを使用してJVMコントローラを管理します。
JVMコントローラは、次の3通りの場合に起動されます。
Fusion Middleware Controlから起動した場合
既存のJVMコントローラにバインドされているFormsアプリケーションがコントローラの起動を要求した場合
コマンドラインから
Fusion Middleware Controlでは、JVMコントローラの構成ファイルが読み取られます。これには、名前と値のペア、デフォルト・セクションおよび名前を付けたセクションが含まれ、Forms構成ファイル(formsweb.cfg
)と同様の機能を果たします。jvmcontrollers.cfg
に含まれるパラメータは、JVMコントローラの起動パラメータに相当します。
注意:
JVMコントローラの構成ファイルのディレクトリや名前を変更することはできません。
JVMコントローラを起動すると、設定が構成ファイルから取得されます。このファイルでは、デフォルト・セクションと名前を付けたセクションの両方で、オプションをまったく指定しないことも、一部またはすべてのオプションを指定することもできます。
Fusion Middleware Controlの「JVM構成」ページと「JVMコントローラ」ページを使用して、次のようなJVMプーリング・タスクを管理します。
この項では、JVM構成ファイルとそのパラメータのセクションで構成を編集するために実行できる、一般的なタスクについて説明します。
次の表では、JVM構成ファイル内の構成セクションで実行できるタスクについて説明します。
表10-4 構成セクションで行うタスク
タスク | 説明 | 備考 |
---|---|---|
類似作成 |
構成セクションのコピーを作成します。 |
既存の構成セクションのパラメータに基づいて構成セクションを作成する際に使用します。 |
編集 |
「説明の編集」ダイアログを開きます。 |
構成セクションの説明テキストを編集できます。 |
削除 |
構成セクションの削除時に「確認」ダイアログを開きます。 |
「確認」ダイアログで「削除」を押すと、構成セクションとその内容が無条件に削除されます。 |
作成 |
「セクションの作成」ダイアログを開きます。 |
新しい構成セクションを作成します。必要な名前とオプションの説明を入力する必要があります。 |
次の表では、名前付き構成セクション内のパラメータを変更するために実行できるタスクについて説明します。
表10-5 名前を付けた構成セクションでのパラメータ処理のタスク
タスク | 説明 | 備考 |
---|---|---|
元に戻す |
以前のバージョンの構成セクションに戻すことができます。 |
構成セクション内の個々の変更を元に戻すことはできません。 |
適用 |
構成セクション内のパラメータに対するすべての変更を適用およびアクティブ化します。 |
一度適用すると、個々のパラメータへの変更を元に戻すことはできません。 |
追加 |
「パラメータの追加」ダイアログを開きます。 |
必須の名前とオプションの値および説明に基づき、構成セクションにパラメータを追加します。 |
削除 |
パラメータを削除します。 |
変更を保存するには「適用」、破棄するには「元に戻す」をそれぞれ使用します。一度適用すると、個々のパラメータへの変更を元に戻すことはできません。 |
この項では、名前を付けたJVM構成セクションの作成、編集、複製および削除について説明します。
「JVM構成」ページにアクセスするには:
Enterprise Manager Fusion Middleware Controlを起動します。
Fusion Middleware Controlのメイン・ページで、構成するForms Servicesインスタンスへのリンクをクリックします。
「Forms」メニュー・リストから「JVM構成」を選択します。「JVM構成」ページが表示されます。
jvmcontrollers.cfg
に新しい構成セクションを作成するには、Fusion Middleware Controlの「JVM構成」ページを使用します。これらの構成は、フォームの実行に使用するエンド・ユーザーのURL問合せ文字列からリクエストできます。
新しい構成セクションを作成するには:
名前を付けた構成のコピーをバックアップ用に作成できます。または、既存の構成セクションから新しい構成セクションを作成できます。
名前を付けた構成を複製するには:
名前を付けた構成セクションを削除すると、構成セクション内の情報はすべて削除されます。特定のパラメータのみを削除する方法は、「パラメータの管理」を参照してください。
名前を付けた構成を削除するには:
注意:
デフォルト構成セクションは削除できません。
名前を付けた構成内のパラメータを管理するには、Fusion Middleware Controlを使用します。Fusion Middleware Controlを使用して、パラメータを追加、編集または削除できます。
構成セクションでパラメータを編集するには:
「JVM構成」リージョンで、編集するパラメータを含む構成セクションの行を選択します。
編集するパラメータの行を選択します。「値」と「コメント」に入力します。
変更を保存する場合は「適用」をクリックし、破棄する場合は「元に戻す」をクリックします。
構成セクションにパラメータを追加するには:
Fusion Middleware Controlの「JVM構成」リージョンで、パラメータを追加する構成セクションの行を選択します。
「追加」をクリックして新しいパラメータを追加します。
「追加」ダイアログが表示されます。
パラメータの「名前」、「値」、および「コメント」に入力します。
パラメータを追加するには、「作成」をクリックします。
変更を保存する場合は「適用」をクリックし、破棄する場合は「元に戻す」をクリックします。
構成セクションのパラメータを削除するには:
次の表に、JVM構成パラメータとそのデフォルト値を示します。
表10-6 JVM構成パラメータのリスト
パラメータ | 説明 | デフォルト値 |
---|---|---|
maxsessions |
新規JVMが生成される前にデフォルトのJVMが処理する、最大同時Oracle Formsセッション数を指定します。 |
65535 |
classpath |
|
|
jvmoptions |
JVMに渡すために有効なオプションを入力します。有効なJVM起動パラメータの詳細は、Oracle Javaドキュメントを参照してください。 |
Null |
logdir |
デフォルトJVMコントローラのログ・ディレクトリを使用する場合は、「ログ・ディレクトリ」を空白のままにしておきます。他のディレクトリが設定されている場合は、ログ・ファイルはEnterprise Managerで表示できません。 |
|
logging |
|
Info |
autoremoval |
|
Off |
loadbalance |
|
ランダム |
Fusion Middleware Controlは、JVMコントローラの起動、停止、再起動など、Oracle Forms Servicesを管理するツールです。Oracle Forms Servicesの管理には、このツールの使用をお薦めします。
JVMコントローラが停止した場合は、起動することができます。JVMコントローラがすでに実行中の場合は、手動で停止せずに再起動することができます。Fusion Middleware Controlでは、自動的にこの手順が実行されます。
注意:
JVMを停止または再起動する前に、JVMコントローラを使用しているFormsセッションをユーザーが停止したことを確認します。JVMを再起動すると、ユーザー側ではセッションの再起動が必要になることがあります。
「JVMコントローラ」ページにアクセスするには:
Enterprise Manager Fusion Middleware Controlを起動します。
「Forms」ホームページで、「JVMコントローラ」を選択します。「JVMコントローラ」ページが表示されます。
実行中でないJVMコントローラを起動するには:
「Forms」メニューで、「JVMコントローラ」を選択します。
「JVMコントローラ」ページが表示されます。
起動するJVMコントローラを選択します。実行されていないJVMコントローラには赤い下矢印が表示されています。
「起動」をクリックします。
JVMコントローラが起動すると、「ステータス」列に緑色の上矢印が表示されます。
実行中のJVMコントローラを再起動するには:
「Forms」メニューで、「JVMコントローラ」を選択します。
「JVMコントローラ」ページが表示されます。
再起動するJVMコントローラを選択します。
「再起動」をクリックします。
「確認」ダイアログで「はい」をクリックします。
「JVMコントローラ」ページが再表示されます。
JVMコントローラが再起動すると、「ステータス」に緑色の上矢印が表示されます。
JVMコントローラを停止するには::
「Forms」メニューで、「JVMコントローラ」を選択します。
「JVMコントローラ」ページが表示されます。
停止する対象となる実行中のJVMコントローラ(緑色の上矢印で表示されているコントローラ)を選択します。
「停止」をクリックします。
「確認」ダイアログで「はい」をクリックします。
JVMコントローラが停止すると、「ステータス」列に赤色の下矢印が表示されます。
JVMコントローラのその他の詳細を表示するには::
この項では、アプリケーションでのJVMコントローラの使用を有効または無効にするためにForms構成ファイル(formsweb.cfg
)で使用するJVMプーリング・パラメータについて説明します。パラメータ名には大/小文字の区別はありません。Fusion Middleware Controlを使用して、Forms構成ファイルを管理できます。
formsweb.cfg
でのパラメータの変更の詳細は、「パラメータの管理」を参照してください。
次の表に、formsweb.cfg
ファイルで指定する起動オプションを示します。
表10-7 Oracle FormsのJVMコントローラ起動パラメータ
パラメータ | 説明 |
---|---|
|
有効値: jvmcontrollerの名前。空白のままにしてJVMを指定しないこともできます。 デフォルト値: なし 注意: このパラメータはデフォルト・セクションでグローバルに設定することも、アプリケーション・セクションを選択してオーバーライドすることもできます。これによって、Formsランタイム・プロセスで使用するJVMコントローラが決まります。dejvm実行可能ファイルの
|
|
有効値: デフォルト値: true JVMコントローラを使用するようにFormsが構成されていて、そのJVMコントローラが実行されていない場合、このパラメータにより、Oracle FormsでJVMコントローラを実行することができます。 |
この例では、複数のアプリケーションで複数のJVMを使用する環境を示します。
次の表に示すように、formsweb.cfg
は4つの構成セクションで構成されます。
図10-8 複数のアプリケーションで使用する複数のJVM
名前付き構成セクション | JVM構成 |
---|---|
|
|
ordersApp |
なし |
hrApp |
|
salesApp |
|
ユーザーがordersApp
アプリケーションを起動し、アプリケーションがJavaコードを実行すると、Formsランタイム・プロセスはそのリクエストをcommonJVM
という名前のJVMコントローラにルーティングします。[ordersApp]
アプリケーション・セクションでは使用するJVMコントローラが指定されていないので、Formsランタイム・プロセスはグローバルなJVMコントローラを使用します。JVMコントローラが起動していない場合は、動的に起動します。別のユーザーが同じアプリケーションを起動すると、同様にcommonJVM
に接続します。
ユーザーがhrApp
アプリケーションを起動し、アプリケーションがJavaコードを実行すると、Formsランタイム・プロセスはそのリクエストをhrJVM
という名前のJVMコントローラに送ります。これは、[hrApp]
アプリケーション・セクションがグローバル設定をオーバーライドするためです。JVMコントローラが起動していない場合は、動的に起動します。別のユーザーが同じアプリケーションを起動すると、同様にhrJVM
に接続します。
ユーザーがsalesApp
アプリケーションを起動し、アプリケーションがJavaコードを実行すると、Java ImporterがJVMプーリングなしで機能するのと同様に、Formsランタイム・プロセスはインプロセスJVMを起動します。2人目のユーザーが同じアプリケーションを起動すると、そのアプリケーションは自身のインプロセスJVMを取得するため、次の図に示すようにメモリーの消費量が多くなります。
ロギングを有効にすると、JVMコントローラによって一定の情報がログ・ファイルに記録されます。
次の情報が記録されます。
JVMパラメータ(maxsessions、classpathなど)の値。
JVMコントローラが起動および終了した日時。
子JVMが生成された日時。
Formsランタイム・プロセスが新規の接続を開始した日時とそのプロセスID。
この情報は、診断または管理の目的でどのFormsランタイム・プロセスがどのJVMコントローラに接続されているかを調べるうえで役立ちます。
Formsランタイム・プロセスのセッションが終了しJVMとの接続が解除された日時。
内容は次のとおりです。
Fusion Middleware Controlを使用して、JVMコントローラのロギング・プロパティを管理します。
ログ・ファイルのディレクトリはJVMコントローラで指定できます。また、他のJVMコントローラが使用するデフォルトJVMコントローラのログ・ファイル・ディレクトリも指定できます。
ログ・ファイルのディレクトリの場所を指定するには:
JVMコントローラの詳細は、「新しい構成セクションの作成」または「名前を付けた構成の複製」を参照してください。
パラメータの管理の詳細は、「パラメータの管理」を参照してください
ログ・ファイルが存在する場合は、「ログ・ファイル」列にアイコンが表示されます。
ログ・ファイルにアクセスするには:
該当のJVMコントローラで使用可能な「ログ・ファイル」列の「ログ・ファイル」リンクをクリックします。
「ログ・ファイル」ページが開き、そのログの情報が表示されます。