10g（10.1.3.1.0）
B31864-01
 目次 |
 索引 |
| Oracle Application Server mod_plsqlユーザーズ・ガイド 10g（10.1.3.1.0） B31864-01 |
|
mod_plsqlは、Web上でのPL/SQLベースのデータベース・アプリケーションの配置をサポートします。mod_plsqlはOracle HTTP Serverの一部であり、Oracle Application ServerおよびOracle Databaseとともに出荷されています。
Oracle HTTP Serverの一部として、WebブラウザからWebサーバーに送信されたURLを解析し、適切なPL/SQLサブプログラムをコールしてブラウザ・リクエストを処理した後、生成されたレスポンスをブラウザに返すことがmod_plsqlの仕事です。通常、mod_plsqlは表示するHTMLページを構成して、WebブラウザのHTTPリクエストにレスポンスを返します。mod_plsqlの用途は他にもありますが、その中の2つを次に示します。
Oracle HTTP Serverへのプラグインとして、mod_plsqlは、HTTPリクエストへのレスポンスでストアド・プロシージャが実行されるようにします。mod_plsqlは、処理されるURLごとに、接続プールのデータベース・セッションを使用するか、または新規セッションを実行中に作成してプールします。mod_plsqlが適切なデータベースPL/SQLプロシージャをURL処理セッションで起動するには、まず、仮想パスを設定し、そのパスとデータベース・アクセス記述子（DAD）を関連付ける必要があります。
DADは、名前付きの設定値のセットで、特定のデータベースのセッションを作成するために必要な情報と、特定のデータベース・ユーザーおよびパスワードを指定します。セッションのデータベース・サービス名およびグローバリゼーション・サポート設定（言語など）が含まれます。詳細は、3.2項「データベース・アクセス記述子（DAD）」を参照してください。
実行時にmod_plsqlによって実行されるストアド・プロシージャを開発するには、PL/SQL Web Toolkitを使用します。PL/SQL Web Toolkitは一連のPL/SQLパッケージで、これを使用するとHTTPリクエストに関する情報の取得、HTTPレスポンス・ヘッダー（HTTPヘッダーのCookie、コンテンツ・タイプ、MIMEタイプなど）の指定、Cookieの設定、およびHTMLページを作成するための標準HTMLタグの生成が可能です。詳細は、『Oracle Application Server PL/SQL Web Toolkitリファレンス』を参照してください。
この章の内容は、次のとおりです。
mod_plsqlは、データベースと通信を行うOracle HTTP Serverのプラグインです。これによって、ブラウザ・リクエストが、SQL*Net接続を通じてデータベース・ストアド・プロシージャ・コールにマッピングされます。通常、仮想パスの/plsで示されます。
次に、サーバーがクライアント・リクエストを受信するときのステップの概要（図3-1）を説明します。
mod_plsqlから実行されたプロシージャは、HTTPレスポンスをクライアントに返します。この作業を簡単にするために、mod_plsqlにはPL/SQL Web Toolkitが含まれています。PL/SQL Web Toolkitには、OWAパッケージと呼ばれるパッケージのセットが含まれています。これらのパッケージをストアド・プロシージャ内で使用して、リクエスト情報の取得、HTMLタグの作成およびクライアントへのヘッダー情報の返信を行います。すべてのユーザーがアクセスできるように、このツールキットは共通スキーマにインストールしてください。
各mod_plsqlリクエストは、データベース・アクセス記述子（DAD）に関連付けられています。DADは、データベース・アクセスに使用される設定値のセットです。DADにより、次のような情報が指定されます。
また、DADにはユーザー名とパスワードの情報を指定できます。指定がない場合には、URLの実行時にユーザー名とパスワードを入力するプロンプトが表示されます。
mod_plsqlをWebブラウザで実行するには、次の形式でURLを入力します。
protocol://hostname[:port]/DAD_location/[[!][schema.][package.]proc_name[?query_string]]
表3-1に、mod_plsql実行時のパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
protocol |
|
|
hostname |
Webサーバーが稼働しているマシンです。 |
|
（オプション） |
Webサーバーがリスニングしているポートです。指定しない場合、ポート80が使用されます。 |
|
DAD location |
Webサーバーで設定したPL/SQLリクエストを処理するための仮想パスです。DAD locationに使用できるのはASCII文字のみです。 |
|
（オプション） |
柔軟なパラメータの受渡しスキームを使用することを示します。詳細は、3.6.2項「柔軟なパラメータの受渡し」を参照してください。 |
|
（オプション） |
データベース・スキーマ名です。指定しない場合、 |
|
（オプション） |
PL/SQLストアド・プロシージャを含んだパッケージです。指定しない場合、プロシージャはスタンドアロンになります。 |
|
proc_name |
実行するPL/SQLストアド・プロシージャです。ファンクションではなく、プロシージャを指定する必要があります。IN引数のみ使用可能です。 |
|
（オプション） |
ストアド・プロシージャのパラメータです。この文字列は、GETメソッドの書式に従います。たとえば、次のようになります。
|
例3-1、例3-2および例3-3に、各種プロシージャの起動方法を示します。
http://www.acme.com:9000/pls/mydad/mypackage.myproc
この場合、www.acme.comで稼働し、ポート9000でリスニングしているWebサーバーがリクエストを処理します。Webサーバーは、リクエストを受信すると、そのリクエストをmod_plsqlに渡します。これは、そのWebサーバーがmod_plsqlを実行するように設定されていることが、/pls/mydadにより示されるためです。次に、mod_plsqlは、/pls/mydadに関連付けられているDADを使用して、mypackageに格納されているmyprocプロシージャを実行します。
http://www.acme.com:9000/pls/mydad/mypackage.myproc?a=v&b=1
この場合、www.acme.comで稼働し、ポート9000でリスニングしているWebサーバーがリクエストを処理します。Webサーバーは、リクエストを受信すると、/pls/mydadに関連付けられているDADを使用して、mypackageに格納されているmyprocプロシージャを実行し、2つの引数aおよびb（それぞれの値はvおよび1）をプロシージャに渡します。
http://www.acme.com:9000/pls/mydad
この場合、www.acme.comで稼働し、ポート9000でリスニングしているWebサーバーがリクエストを処理します。Webサーバーは、リクエストを受信すると、/pls/mydadに関連付けられているDADを使用して、DADに設定されているデフォルト・プロシージャを実行します。たとえば、DAD /pls/mydadの構成パラメータPlsqlDefaultPageがmyschema.mypackage.myprocに設定されている場合、プロシージャmyschema.mypackage.myprocがリクエストに対して実行されます。
この例では、DAD設定に指定されているmydadというDADのデフォルトのホームページが表示されます。
HTTPプロトコルのPOSTメソッド、GETメソッドおよびHEADメソッドは、パラメータ・データをアプリケーションに渡す方法（通常は名前/値ペア形式）をブラウザに対して指示します。パラメータ・データはHTMLフォームによって生成されます。
mod_plsqlアプリケーションでは、いずれのメソッドも使用できます。各メソッドの保護レベルは、使用する転送プロトコル（HTTPまたはHTTPS）によって決定されます。
foo（a varchar2、b number）で、値vと1をそれぞれaとbに渡す場合は、次の3つの方法で値を渡してURLを作成できます。
プロシージャを実行するためにURLリクエストを処理した後、エラーがあれば、mod_plsqlによりロールバックが実行されます。そうでない場合は、コミットが実行されます。このメカニズムでは、トランザクションが複数のHTTPリクエストにまたがることはできません。この状態を保持しないモデルの場合、アプリケーションは、通常HTTP Cookieまたはデータベース表を使用して状態を維持します。
HTTPでサポートされるのはキャラクタ・ストリームのみのため、mod_plsqlではPL/SQLデータ型の次のサブセットがサポートされます。
レコードはサポートされません。
mod_plsqlは、次の処理をサポートしています。
プロシージャまたはファンクションを起動するURL内の各パラメータは、一意の名前により識別されます。パラメータのオーバーロードがサポートされています。詳細は、3.6.1項「名前によるパラメータの受渡し（パラメータのオーバーロード）」を参照してください。
プロシージャの先頭に感嘆符（!）が付加されます。詳細は、3.6.2項「柔軟なパラメータの受渡し」を参照してください。
詳細は、3.6.3項「大きなパラメータの受渡し」を参照してください。
オーバーロードにより、名前が同じでパラメータの数、順序またはデータ型のファミリが異なる複数のサブプログラム（プロシージャまたはファンクション）を使用できます。オーバーロードされたサブプログラムをコールすると、PL/SQLコンパイラは渡されたデータ型に基づいて、どのサブプログラムをコールするかを決定します。
PL/SQLでは、ローカル・サブプログラムとパッケージ・サブプログラムをオーバーロードできます。スタンドアロン・サブプログラムはオーバーロードできません。
パラメータ数が同じサブプログラムをオーバーロードする場合は、パラメータに違う名前を付ける必要があります。HTMLデータはデータ型に関連付けられないため、mod_plsqlは、どのバージョンのサブプログラムをコールすればよいか判断できません。
たとえば、PL/SQLでは、次の例に示すように、プロシージャに対して同じパラメータ名を使用して2つのプロシージャを定義できますが、これをmod_plsqlで使用するとエラーが発生します。
-- legal PL/SQL, but not for mod_plsql CREATE PACKAGE my_pkg AS PROCEDURE my_proc (val IN VARCHAR2); PROCEDURE my_proc (val IN NUMBER); END my_pkg;
エラーを回避するには、パラメータに異なる名前を付けます。たとえば、次のようになります。
-- legal PL/SQL and also works for mod_plsql CREATE PACKAGE my_pkg AS PROCEDURE my_proc (valvc2 IN VARCHAR2); PROCEDURE my_proc (valnum IN NUMBER); END my_pkg;
最初のバージョンのプロシージャを実行するURLは次のようになります。
http://www.acme.com:9000/pls/mydad/my_pkg.my_proc?valvc2=input
2番目のバージョンのプロシージャを実行するURLは次のようになります。
http://www.acme.com:9000/pls/mydad/my_pkg.my_proc?valnum=34
パラメータ名が同じで、1つのプロシージャのデータ型がowa_util.ident_arr（varchar2の表）、もう1つのプロシージャのデータ型がスカラー型のオーバーロードPL/SQLプロシージャがあるとします。このような場合でも、mod_plsqlはこの2つのプロシージャを区別できます。たとえば、次のプロシージャがあるとします。
CREATE PACKAGE my_pkg AS PROCEDURE my_proc (val IN VARCHAR2); -- scalar data type PROCEDURE my_proc (val IN owa_util.ident_arr); -- array data type END my_pkg;
これらのプロシージャには、それぞれvalという同じ名前のパラメータが1つあります。
mod_plsqlは、valパラメータの値を1つだけ持つリクエストを受け取ると、例3-4に示すように、スカラー・データ型のプロシージャを実行します。
次のURLを送信して、スカラー・バージョンのプロシージャを実行します。
http://www.acme.com:9000/pls/mydad/my_proc?val=john
mod_plsqlは、valパラメータの値が複数存在するリクエストを受け取ると、例3-5に示すように、配列データ型のプロシージャを実行します。
次のURLを送信して、配列バージョンのプロシージャを実行します。
http://www.acme.com:9000/pls/mydad/my_proc?val=john&val=sally
確実に配列バージョンを実行できるようにする場合は、HTMLページでHIDDENフォーム・エレメントを使用してダミーの値を送信します。このダミーの値は、プロシージャ内でチェックされ、破棄されます。
ユーザーがエレメントを必要な数だけ選択できるようなHTMLフォームを使用できます。これらのエレメントにそれぞれ異なる名前が付いている場合は、オーバーロード・プロシージャを作成して可能な組合せを個別に処理する必要があります。または、問合せ文字列に含まれる名前が、ユーザーが選択するエレメントに関係なく確実に毎回一貫したものになるように、HIDDENフォーム・エレメントを挿入できます。mod_plsqlは、ユーザーが任意の数のエレメントを選択できるHTMLフォームを処理するために、柔軟なパラメータの受渡しをサポートすることで、この操作を容易にします。
URLベースのプロシージャの実行で柔軟なパラメータの受渡しを使用するには、URL内でプロシージャ名の先頭に感嘆符（!）を付加します。2パラメータまたは4パラメータを使用できます。2パラメータ・インタフェースによって、mod_plsqlのパフォーマンスが改善されます。
4パラメータ・インタフェースは、互換性維持のためにサポートされています。
procedure [proc_name] (name_array IN [array_type], value_array IN [array_type]);
表3-2に、2パラメータ・インタフェースのパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
（必須） |
実行するPL/SQLプロシージャの名前です。 |
|
|
問合せ文字列から取り出される名前（1から順番に索引付けされる）を送信された順序で示します。 |
|
|
問合せ文字列から取り出される値（1から順番に索引付けされる）を送信された順序で示します。 |
|
（必須） |
varchar2型（owa.vc_arrなど）の表による任意のPL/SQL索引です。 |
例3-6に、2パラメータ・インタフェースの使用について示します。
次のURLを送信します。
http://www.acme.com:9000/pls/mydad/!scott.my_proc?x=john&y=10&z=doe
感嘆符（!）接頭辞により、柔軟なパラメータの受渡しを使用することがmod_plsqlに指示されます。これにより、プロシージャscott.myprocが実行され、次の2つの引数が渡されます。
name_array ==> ('x', 'y', 'z') value_array ==> ('john', '10', 'doe')
4パラメータ・インタフェースは、互換性維持のためにサポートされています。
procedure [proc_name] (num_entires IN NUMBER, name_array IN [array_type], value_array IN [array_type], reserved in [array_type]);
表3-3に、4パラメータ・インタフェースのパラメータを示します。
例3-7に、4パラメータ・インタフェースの使用について示します。
query_stringで名前xが重複している次のURLを送信します。
http://www.acme.com:9000/pls/mydad/!scott.my_pkg.my_proc?x=a&y=b&x=c
感嘆符（!）接頭辞により、柔軟なパラメータの受渡しを使用することがmod_plsqlに指示されます。これにより、プロシージャscott.my_pkg.myprocが実行され、次の2つの引数が渡されます。
num_entries ==> 3 name_array ==> ('x', 'y', 'x'); value_array ==> ('a', 'b', 'c') reserved ==> ()
スカラー引数として渡される値と、varchar2引数の索引付き表の要素として渡される値に使用できるサイズは、最大32KBです。
たとえば、柔軟なパラメータの受渡し（3.6.2項「柔軟なパラメータの受渡し」を参照）を使用する場合、URLのquery_string部分の名前または値は、それぞれ実行されるプロシージャのname_arrayまたはvalue_array引数のエレメントとして渡されます。これらの名前または値に使用できるサイズは、最大32KBです。
mod_plsqlでは、次の機能を提供します。
http://www.acme.com:9000/pls/mydad/docs/cs250/lecture1.htm
これは、URLの相互参照を含んだファイル・セットのアップロードをサポートするために必要です。
この項の内容は、次のとおりです。
DADごとにドキュメント格納表を指定できます。ドキュメント格納表には、次の定義が必要です。
CREATE TABLE [table_name] ( NAME VARCHAR2(256) UNIQUE NOT NULL, MIME_TYPE VARCHAR2(128), DOC_SIZE NUMBER, DAD_CHARSET VARCHAR2(128), LAST_UPDATED DATE, CONTENT_TYPE VARCHAR2(128), [content_column_name] [content_column_type] [ , [content_column_name] [content_column_type]] );
table_nameは、ユーザーが選択できます。content_column_type型には、LONG RAWまたはBLOBのいずれかを使用します。
content_column_nameは、対応するcontent_column_typeによって異なります。
content_column_nameはCONTENTにする必要があります。
content_column_nameはBLOB_CONTENTにする必要があります。
次に、有効なドキュメント表の定義例を示します。
CREATE TABLE MYDOCTABLE ( NAME VARCHAR(256) UNIQUE NOT NULL, MIME_TYPE VARCHAR(128), DOC_SIZE NUMBER, DAD_CHARSET VARCHAR(128), LAST_UPDATED DATE, CONTENT_TYPE VARCHAR(128), CONTENT LONG RAW, BLOB_CONTENT BLOB ; );
表の内容は、CONTENT列に格納されます。ドキュメント表には、複数のCONTENT列を含めることが可能です。ただし、ドキュメント表の各行について、CONTENT列は1つのみ使用されます。その他のCONTENT列はNULLに設定されます。
CONTENT_TYPE列は、ドキュメントが格納されているCONTENT列を追跡するために使用されます。ドキュメントがアップロードされると、mod_plsqlにより、この列の値が型名に設定されます。
たとえば、ドキュメントがBLOB_CONTENT列にアップロードされた場合、ドキュメントのCONTENT_TYPE列には文字列BLOBが設定されます。
LAST_UPDATED列には、ドキュメントの作成日時または最終更新日時が反映されます。ドキュメントがアップロードされると、mod_plsqlにより、ドキュメントのLAST_UPDATED列にデータベース・サーバーの時間が設定されます。
その後、アプリケーションがドキュメントの内容または属性を変更する場合、LAST_UPDATEDの時間も更新されるようにする必要があります。
mod_plsqlでは、LAST_UPDATED列を使用して、HTTPクライアント（ブラウザ）がドキュメントのキャッシュ済バージョンを使用できるかどうかをチェックし、HTTPクライアントに結果を知らせます。これにより、ネットワークの通信量が削減され、サーバーのパフォーマンスが改善されます。
DAD_CHARSET列は、ファイルのアップロード時のキャラクタ・セット設定を追跡します。この列は、今後使用するために予約されています。
WebDBリリース2.xより前のリリースで使用されているドキュメント・モデルとの下位互換性を維持するために、mod_plsqlでは、CONTENT_TYPE、DAD_CHARSETおよびLAST_UPDATED列が存在しない、以前のドキュメント格納表の定義もサポートしています。
/* older style document table definition (DEPRECATED) */ CREATE TABLE [table_name] ( NAME VARCHAR2(128), MIME_TYPE VARCHAR2(128), DOC_SIZE NUMBER, CONTENT LONG RAW );
DADの次の設定パラメータが、ドキュメントのアップロードまたはダウンロード操作に影響します。
例3-8に、構成パラメータの使用とその結果について示します。
DADでこれらのパラメータが次のように設定されているとします。
PlsqlDocumentTablename scott.my_document_table PlsqlUploadAsLongRaw html PlsqlDocumentPath docs PlsqlDocumentProcedure scott.my_doc_download_procedure
この場合は次のようになります。
.htmlを除くすべてのファイル拡張子は、ドキュメント表にBLOBとしてアップロードされます。.html拡張子が付いたファイルはすべてLong Rawとしてアップロードされます。
通常、このプロシージャはwpg_docload.download_fileをコールして、URL指定に基づく名前を持ったファイルのダウンロードを開始します。
次に前述の構成の単純な例を示します。
http://www.acme.com:9000/pls/dad/docs/index.html
この場合は、scott.my_document_tableデータベース表のLong Raw列からindex.htmlファイルがダウンロードされます。アプリケーション・プロシージャは開始するファイルのダウンロードを完全に制御し、ファイル・レベルのアクセス制御とバージョニングを実装する、より複雑なPlsqlDocumentProcedureを柔軟に定義することに注意してください。
PlsqlDocumentTablenameパラメータは、このDADによってファイルがアップロードされたときにドキュメントを格納する表を指定します。
構文:
PlsqlDocumentTablename [document_table_name] PlsqlDocumentTablename my_documents
または
PlsqlDocumentTablename scott.my_document_table
PlsqlDocumentPathパラメータは、ドキュメントにアクセスするためのパス・エレメントを指定します。PlsqlDocumentPathパラメータは、URL内でDAD名の後に付加されます。たとえば、ドキュメント・アクセス・パスがdocsの場合、URLは次のようになります。
http://www.acme.com:9000/pls/mydad/docs/myfile.htm
mydadはDAD名で、myfile.htmはファイル名です。
構文:
PlsqlDocumentPath [document_access_path_name]
PlsqlDocumentProcedureプロシージャは、アプリケーション指定のプロシージャです。このプロシージャはパラメータがなく、ドキュメント・アクセス・パスを持つURLリクエストを処理します。ドキュメント・アクセス・プロシージャは、ファイルをダウンロードするために、wpg_docload.download_file(filename)をコールします。ドキュメント・アクセス・プロシージャは、URL指定に基づいてファイル名を認識します。たとえば、アプリケーションでこれを使用して、ファイル・レベルのアクセス制御やバージョン管理を実装することが可能です。このようなアプリケーションの例は、3.7.7項「ファイルのダウンロード」にあります。
構文:
PlsqlDocumentProcedure [document_access_procedure_name]
例3-9に、PlsqlDocumentProcedureプロシージャの使用について示します。
PlsqlDocumentProcedure my_access_procedure
または
PlsqlDocumentProcedure scott.my_pkg.my_access_procedure
DADパラメータPlsqlUploadAsLongRawは、ファイル拡張子に基づいてファイルのアップロードを設定します。PlsqlUploadAsLongRaw DADパラメータの値は、1行に1つのエントリがあるファイル拡張子のリストです。これらの拡張子を持つファイルは、mod_plsqlにより、ドキュメント表のLONG RAW型のCONTENT列にアップロードされます。他の拡張子を持つファイルは、BLOB CONTENT列にアップロードされます。
ファイル拡張子には、テキスト・リテラル（jpeg、gifなど）またはアスタリスク（*）を使用できます。アスタリスクは、PlsqlUploadAsLongRaw設定でリストされていない拡張子を持つすべてのファイルと一致します。
構文:
PlsqlUploadAsLongRaw [file_extension] PlsqlUploadAsLongRaw *
例3-10に示すように、
[file_extension]はファイル拡張子（ピリオド（.）の有無は関係なく、たとえば、txtまたは.txtが使用できます）またはワイルド・カード文字（*）です。
例3-10に、PlsqlUploadAsLongRawパラメータの使用について示します。
PlsqlUploadAsLongRaw html PlsqlUploadAsLongRaw txt PlsqlUploadAsLongRaw *
クライアント・マシンからデータベースにファイルを送信する場合は、次に示す内容を含んだHTMLページを作成します。
enctype属性にmultipart/form-dataが設定され、action属性に「アクション・プロシージャ」と呼ばれるmod_plsqlプロシージャ・コールが関連付けられているFORMタグ。
INPUT type="file"エレメントを使用すると、ユーザーはファイル・システムのファイルを参照して、そこからファイルを選択できます。
ユーザーが「Submit」ボタンをクリックすると、次のイベントが発生します。
PlsqlDocumentTablename DAD設定から取得されます。
action属性で指定したアクション・プロシージャが、ファイルのアップロードを行わずにmod_plsqlプロシージャを実行する場合と同じように実行されます。次の例に、アップロードするファイルをユーザーがファイル・システムから選択できるHTMLフォームを示します。このフォームには、ファイルに関する情報を入力できるその他のフィールドも含まれています。
<html> <head> <title>test upload</title> </head> <body> <FORM enctype="multipart/form-data" action="pls/mydad/write_info" method="POST"> <p>Author's Name:<INPUT type="text" name="who"> <p>Description:<INPUT type="text" name="description"><br> <p>File to upload:<INPUT type="file" name="file"><br> <p><INPUT type="submit"> </FORM> </body> </html>
ユーザーがフォームの「Submit」ボタンをクリックすると、次の処理が実行されます。
INPUT type="file"エレメントにリストされたファイルがアップロードされます。
write_infoプロシージャが実行されます。
procedure write_info ( who in varchar2, description in varchar2, file in varchar2) as begin insert into myTable values (who, description, file); htp.htmlopen; htp.headopen; htp.title('File Uploaded'); htp.headclose; htp.bodyopen; htp.header(1, 'Upload Status'); htp.print('Uploaded ' || file || ' successfully'); htp.bodyclose; htp.htmlclose; end;
名前の競合の可能性を低減するために、ブラウザから取得したファイル名の先頭に、生成されたディレクトリ名が付加されます。フォームで指定されたアクション・プロシージャにより、この名前が変更されます。このため、たとえば/private/minutes.txtがアップロードされた場合、mod_plsqlによって表に格納される名前は、F9080/private/minutes.txtとなります。アプリケーションは、コールしたストアド・プロシージャの中で、この名前を変更できます。たとえば、アプリケーションにより、名前をscott/minutes.txtに変更できます。
ストアド・プロシージャは、アップロード・ファイルの名前を変更する以外にも、他のファイル属性を変更できます。たとえば、3.7.4項「ファイルのアップロード」に示した例のフォームでは、アップロードされるドキュメントのMultipurpose Internet Mail Extension（MIME）タイプをユーザーが入力できるフィールドとして表示できます。
MIMEタイプは、write_infoのパラメータとして受信できます。その場合、ドキュメント表には、ファイルのアップロード時にmod_plsqlがマルチパート・フォームから解析したデフォルトのMIMEタイプではなく、そのドキュメントのMIMEタイプが格納されます。
1回の送信で複数のファイルを送信する場合は、アップロード・フォームに複数の<INPUT type="file" name="file">エレメントが含まれている必要があります。複数のファイルのINPUTエレメントで、 nameに同じ名前を定義する場合、アクション・プロシージャでパラメータ名をowa.vc_arr型として宣言する必要があります。ファイルのINPUTエレメントに一意の名前を定義することも可能で、その場合、アクション・プロシージャでそれぞれをvarchar2として宣言する必要があります。たとえば、フォームに次のエレメントが含まれているとします。
<INPUT type="file" name="textfiles"> <INPUT type="file" name="textfiles"> <INPUT type="file" name="binaryfile">
この場合、アクション・プロシージャに次のパラメータを含める必要があります。
procedure handle_text_and_binary_files(textfiles IN owa.vc_arr, binaryfile IN varchar2)
ファイルをデータベースにアップロードした後、次に説明する3つの方法で、それらのファイルをデータベースからダウンロードできます。
wpg_docload.download_file(file_name)をコールしてファイルfile_nameをダウンロードするPL/SQLプロシージャを定義します。
PlsqlDocumentPath）をDAD設定に定義し、ユーザー定義のプロシージャ（PlsqlDocumentProcedure）とそのパスを関連付けます。mod_plsqlは、DAD名のすぐ後ろにPlsqlDocumentPathで指定された仮想パスを検出すると、ユーザー定義のプロシージャ（PlsqlDocumentProcedure）を自動的に起動します。このプロシージャは、wpg_docload.download_file(file_name)をコールしてファイルfile_nameのダウンロードを開始する必要があります。追加の引数を渡さずに起動されるように、このユーザー定義のプロシージャにはプロトタイプが必要です。たとえば、DADのmydadでPlsqlDocumentPathがdocsとして、PlsqlDocumentProcedureがmyschema.pkg.process_downloadとして構成されている場合、URLの形式がhttp://www.acme.com:9000/pls/mydad/docs/myfile.htmのときは常に、mod_plsqlはプロシージャmyschema.pkg.process_downloadを実行します。
次に、process_downloadの実装例を示します。
procedure process_download is v_filename varchar2(255); begin -- getfilepath() uses the SCRIPT_NAME and PATH_INFO cgi -- environment variables to construct the full path name of -- the file URL, and then returns the part of the path name -- following '/docs/' v_filename := getfilepath; select name into v_filename from plsql_gateway_doc where UPPER(name) = UPPER(v_filename); -- now we call docload.download_file to initiate -- the download. wpg_docload.download_file(v_filename); exception when others then v_filename := null; end process_download;
wpg_docload.download_file(blob_name)を起動してBLOBのblob_nameをダウンロードします。
wpg_docload.download_file(blob)をコールするストアド・プロシージャを作成します。blobはBLOBデータ型です。mod_plsqlにはBLOBの内容に関する情報が含まれていないため、情報を入力する必要があります。
次の例では、プロシージャは引数の名前を使用して表からBLOBを選択し、BLOBのダイレクト・ダウンロードを開始します。
create or replace procedure download_blob(name in varchar2) is myblob blob; begin
select blob_data into myblob from mytable where blob_name = name;
owa_util.mime_header('text/html', FALSE); htp.p('Content-Length: ' || dbms_lob.getlength(myblob)); owa_util.http_header_close;
wpg_docload.download_file(myblob); end;
mytable表の構造は、次のとおりです。
create table mytable ( blob_name varchar2(128), blob_data blob );
ドキュメント・ダウンロードが開始されても、BLOBのダイレクト・ダウンロードが使用されない場合は、wpg_docload.download_fileに渡される引数により、ファイル名を一意に識別してドキュメント表からダウンロードできるようにする必要があります。このようなドキュメントの内容の返信時に、mod_plsqlは、そのファイル名に対するドキュメント表エントリの他の列に格納された情報に基づいて、HTTPレスポンス・ヘッダーを生成します。MIME_TYPE列、DOC_SIZE列およびLAST_UPDATED列はそれぞれ、レスポンス・ヘッダーのContent-Typeヘッダー、Content-LengthヘッダーおよびIf-Modified-Sinceヘッダーを追加するために使用されます。
Windowsプラットフォームでmod_plsqlを使用しており、マルチバイト・キャラクタ・セット（日本語または韓国語）の一部として特殊文字0x5cを含むマルチバイト・データベースに対して実行している場合、ファイルdads.confを変更して、アプリケーションへのアクセスに使用されるDADを編集する必要があります。このためには、次のようにします。
ORACLE_HOME/Apache/modplsql/conf/dads.confファイルを開きます。
WindowsFileConversion Offの行をこのDADエントリに追加します。
DAD設定を更新しないと、ファイル名に0x5cが含まれるドキュメントのダウンロード時に障害が発生します。たとえば、次のようになります。
Error: Document not found (WWC-46000)
HTTP-404 Not Found
パスのエイリアシングにより、mod_plsqlを使用するアプリケーションは、単純なURLによるアプリケーション内のオブジェクトへの直接参照を提供できます。この機能は、ドキュメント・ダウンロード機能の提供方法を汎用化するものです。パスのエイリアシングには、DADの次の設定パラメータを使用します。
たとえば、DADでこれらのパラメータが次のように設定されているとします。
PlsqlPathAlias myalias PlsqlPathAliasProcedure scott.my_path_alias_procedure
この場合、DAD locationの直後にmyaliasキーワードを含むすべてのURLで、scott.my_path_alias_procedureプロシージャが実行されます。このプロシージャは、URL指定に基づいて適切なレスポンスを開始できます。
OWA_UTILパッケージには、CGI環境変数の値を取得するためのAPIが付属しています。CGI環境変数の値は、mod_plsqlによって実行されるプロシージャにコンテキストを提供します。mod_plsqlはCGIによって処理されませんが、mod_plsqlから実行されるPL/SQLアプリケーションは、これらのCGI環境変数にアクセス可能です。
CGI環境変数のリストは次のとおりです。
PL/SQLアプリケーションは、owa_util.get_cgi_envインタフェースを使用してCGI環境変数の値を取得できます。
構文:
owa_util.get_cgi_env(param_name in varchar2) return varchar2;
param_nameは、CGI環境変数の名前です。param_nameには大/小文字区別があります。
PlsqlCGIEnvironmentList DADパラメータは、1行に1つのエントリがある、名前/値ペアのリストです。任意の環境変数のオーバーライドや、新規の環境変数の追加ができます。名前が付属の環境変数（3.9項「Common Gateway Interface（CGI）環境変数」のリストを参照）の1つである場合、その環境変数は指定した値でオーバーライドされます。名前が付属の環境変数のリストにない場合は、パラメータで指定された名前および値と同じ新規の環境変数がリストに追加されます。
パラメータの値が指定されていない場合は、Oracle HTTP Serverから値が取得されます。Oracle HTTP Serverの場合は、次のように指定してCGI環境変数のDOCUMENT_ROOTを渡すことができます。
PlsqlCGIEnvironmentList DOCUMENT_ROOT
この設定パラメータから渡された新規の環境変数は、owa_util.get_cgi_envインタフェースを経由してPL/SQLアプリケーションで使用できます。
例3-11に、環境変数のオーバーライドが指定されたPlsqlCGIEnvironmentListの使用について示します。
PlsqlCGIEnvironmentList SERVER_NAME=myhost.mycompany.com PlsqlCGIEnvironmentList REMOTE_USER=testuser
この例では、CGI環境変数のSERVER_NAMEとREMOTE_USERが付属の環境変数リストに含まれているため、これらの環境変数が指定の値にオーバーライドされます。
例3-12に、新規の環境変数が指定されたPlsqlCGIEnvironmentListの使用について示します。
PlsqlCGIEnvironmentList MYENV_VAR=testing PlsqlCGIEnvironmentList SERVER_NAME= PlsqlCGIEnvironmentList REMOTE_USER=user2
この例では、SERVER_NAME変数とREMOTE_USER変数がオーバーライドされます。SERVER_NAME変数は、値が指定されていないため、削除されます。MYENV_VARという新規の環境変数は、付属の環境変数のリストに含まれていないため追加されます。この環境変数には、testingという値が割り当てられます。
mod_plsqlでは、PlsqlNLSLanguageのDADレベルの設定により、グローバリゼーション・サポート設定が制御されます。DADレベルでPlsqlNLSLanguageが設定されていない場合、グローバリゼーション・サポート設定にはOracleのNLS_LANGパラメータの環境設定が使用されます。このパラメータの詳細は、『Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。
CGI環境変数REQUEST_CHARSETは、PlsqlNLSLanguageの設定に基づいて設定されます。DADレベルでPlsqlNLSLanguageが設定されていない場合、グローバリゼーション・サポート設定にはOracleのNLS_LANGパラメータの環境設定が使用されます。
PL/SQLアプリケーションは、ファンクション・コールによってこの情報にアクセスできます。たとえば、次のようになります。
owa_util.get_cgi_env('REQUEST_CHARSET');
これは、CGI環境変数REQUEST_CHARSETに相当するIANA（Internet Assigned Number Authority）の環境変数です。IANAは、インターネット上のキャラクタ・セットの標準をグローバルに調整する機関です。
PL/SQLアプリケーションは、ファンクション・コールによってこの情報にアクセスできます。たとえば、次のようになります。
owa_util.get_cgi_env('REQUEST_IANA_CHARSET');
キャッシングを使用すると、PL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。パフォーマンスを向上させるために、中間層のPL/SQLプロシージャによって生成されたWebコンテンツをキャッシュして、データベースのワークロードを減少させることができます。
この項では、次のようなキャッシングの方式について説明します。
これらの方式およびレベルは、PL/SQL Web Toolkitに含まれるowa_cacheパッケージを使用して実装されます。
通常、検証方式では、ページが最後に提示されてから変更があったかどうかをサーバーに確認します。ページが変更されていない場合、キャッシュされたページがユーザーに提示されます。ページが変更されている場合、新しいコピーを取得してユーザーに提示した後、それをキャッシュします。
検証方式を使用する方法には、Last-Modified方法およびEntity Tag方法の2つがあります。次の2つの項では、これらの方式がHTTPプロトコルでどのように使用されるかを示します。PL/SQL GatewayではHTTPプロトコルを使用しませんが、多くの同じ原則が使用されます。
WebページがHTTPプロトコルを使用して生成されると、そのページにはLast-Modifiedレスポンス・ヘッダーが含まれます。このヘッダーは、リクエストされたコンテンツの日付（サーバーを基準とする）を示しています。ブラウザは、この日付情報をコンテンツとともに保存します。後続のリクエストがWebページのURLに対して作成されると、ブラウザは次の処理を行います。
キャッシュ対応のサーバーは、If-Modified-Sinceヘッダーを探し、それをコンテンツの日付と比較します。この2つが一致する場合は、「HTTP/1.1 304 Not Modified」などのHTTPレスポンス・ステータス・ヘッダーが生成され、コンテンツは返されません。このステータス・コードを受け取ると、キャッシュ・エントリは有効であるため、ブラウザはそれを再利用できます。
この2つが一致しない場合は、「HTTP/1.1 200 OK」などのHTTPレスポンス・ヘッダーが生成され、新しいコンテンツが、新しいLast-Modifiedレスポンス・ヘッダーとともに返されます。このステータス・コードを受け取ると、ブラウザはキャッシュ・エントリを新しいコンテンツおよび新しい日付情報で置き換える必要があります。
HTTPプロトコルによって提供されるもう1つの検証方法は、ETag（Entity Tag）レスポンス/リクエスト・ヘッダーです。このヘッダーの値は、ブラウザに対して不明瞭な文字列です。サーバーは、この文字列をアプリケーションのタイプに基づいて生成します。この方法は、日付値のみを含めることができるIf-Modified-Sinceヘッダーよりも一般的な検証方法です。
ETag方法は、Last Modified方法とよく似ています。サーバーは、レスポンス・ヘッダーの一部としてETagを生成します。ブラウザは、この不明瞭なヘッダー値を返されたコンテンツとともに格納します。このコンテンツに対する次のリクエストを受信すると、ブラウザは、格納された不明瞭な値をIf-Matchヘッダーに設定してサーバーに渡します。サーバーがこの不明瞭な値を生成しているため、何をブラウザに返すかを判別できます。その他は、前述したLast-Modified検証方法とまったく同じです。
HTTP検証キャッシングをフレームワークとして使用すると、mod_plsqlの検証モデルは次のようになります。
処理されるコンテンツを制御するPL/SQLベースのWebアプリケーションでは、この種のキャッシングを使用する必要があります。この方式を使用すると、適度にパフォーマンスが改善されます。たとえば、常に変わる動的コンテンツを処理するWebアプリケーションがこれに該当します。この場合、Webアプリケーションには、処理対象に対する完全な制御が必要です。検証キャッシングでは、キャッシュされたコンテンツが古いものか、またはブラウザに返された後のものであるかをWebアプリケーションに常に確認します。
図3-2に、mod_plsqlでの検証方式の使用について示します。
owa_cacheプロシージャをコールし、タグおよびキャッシュ・レベルを設定します。
owa_cache.set_cache(p_etag, p_level);
表3-4に、検証モデルのパラメータを示します。
mod_plsqlの検証方式を使用し、クライアント・ブラウザによって、同じPL/SQLプロシージャに対する2番目のリクエストが作成されます。
図3-3に、検証方式を使用した2番目のリクエストを示します。
owa_cacheファンクションをコールします。
owa_cache.get_etag; owa_cache.get_level;
これらのowaファンクションが、タグおよびキャッシング・レベルを取得します。
検証モデルでは、mod_plsqlは、キャッシュからコンテンツを提供できるかどうかを常にPL/SQLプロシージャに確認します。期限モデルでは、プロシージャはコンテンツの有効期間をあらかじめ設定します。そのため、mod_plsqlは、プロシージャに確認することなくキャッシュからコンテンツを提供できます。この方式では、データベースとのやり取りが必要ないため、パフォーマンスが一層向上します。
このキャッシング方式を使用すると、最高のパフォーマンスが得られます。PL/SQLベースのWebアプリケーションにおいて、古いコンテンツの提供が問題にならない場合に使用します。たとえば、ニュースを毎日生成するアプリケーションがこれに該当します。ニュースは24時間有効に設定できます。24時間以内であれば、アプリケーションとやり取りせずにキャッシュされたコンテンツが提供されます。これは、基本的にファイルの提供と同じです。24時間を経過すると、mod_plsqlは再度新しいコンテンツをアプリケーションから取得します。
検証モデルで説明したものと同じシナリオを考えてみます。ただし、プロシージャではキャッシングに期限モデルを使用します。
図3-4に、mod_plsqlでの期限方式の使用について示します。
owa_cacheプロシージャをコールし、有効期間およびキャッシュ・レベルを設定します。
owa_cache.set_expires(p_expires, p_level);
表3-5に、期限モデルのパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
|
期限キャッシングを使用していることをmod_plsqlに通知するためのヘッダーを設定します。その後、mod_plsqlは、有効期間およびキャッシング・レベル情報とともにコンテンツをファイル・システムにキャッシュします。 |
|
|
コンテンツが有効な分数。 |
|
|
キャッシング・レベル。 |
前述の同じ期限モデルを使用し、クライアント・ブラウザによって、同じPL/SQLプロシージャに対する2番目のリクエストが作成されます。
図3-5に、期限方式を使用した2番目のリクエストを示します。
PL/SQLプロシージャは、生成されたコンテンツがシステム・レベルのコンテンツか、ユーザー・レベルのコンテンツかを判断します。これにより、複数のユーザーが同じコンテンツを参照している場合、PL/SQL Gatewayキャッシュによる重複ファイルの格納を減らすことができます。判断は、次の基準で行われます。
SYSTEMをキャッシング・レベル・パラメータとしてowa_cacheファンクションに渡します（検証モデルの場合はset_cache、期限モデルの場合はset_expires）。これは、キャッシュを共有するすべてのユーザーに対して行われます。システム・レベル・キャッシングを使用すると、ファイル・システムの領域とシステム内のすべてのユーザーに費やす時間の両方を節約できます。たとえば、そのWebアプリケーションを使用しているすべてのユーザーを対象としたコンテンツを生成するWebアプリケーションがこれに該当します。システム・レベル設定でコンテンツをキャッシングすると、コンテンツのコピーは1つのみファイル・システムにキャッシュされます。さらに、コンテンツはキャッシュからディレクトリに提供されるため、そのシステムのすべてのユーザーにメリットがあります。
USERをキャッシング・レベルのパラメータとして渡します。これは、ログインしている特定のユーザーに対して行われます。格納されるキャッシュはそのユーザー独自のものです。そのユーザーのみがキャッシュを使用できます。ユーザーのタイプは、認証モードによって決まります。様々なユーザーのタイプは、表3-6を参照してください。| 認証モード | ユーザーのタイプ |
|---|---|
|
Single Sign-On（SSO） |
軽量ユーザー |
|
Basic |
データベース・ユーザー |
|
カスタム |
リモート・ユーザー |
たとえば、PL/SQLベースのWebアプリケーションをカスタマイズしているユーザーがいない場合、出力はシステム・レベル・キャッシュに格納できます。システムのすべてのユーザーに対してキャッシュ・コピーは1つしかありません。複数のユーザーがキャッシュを使用できるため、ユーザー情報は使用されません。
ただし、ユーザーがアプリケーションをカスタマイズしている場合、ユーザー・レベル・キャッシュはそのユーザーに対してのみ格納されます。他のすべてのユーザーは、引き続きシステム・レベル・キャッシュを使用します。ユーザー・レベル・キャッシュ・ヒットにおいては、ユーザー情報が基準となります。ユーザー・レベル・キャッシュは、常にシステム・レベル・キャッシュをオーバーライドします。
検証方式または期限方式のどちらを使用するのかによって、コールするowa_cacheのファンクションが決まります。
owa_cacheパッケージには、特別なキャッシング・ヘッダーおよび環境変数を設定および取得するプロシージャが含まれます。開発者は、これらのプロシージャを使用すると、PL/SQL Gatewayキャッシュをより簡単に使用できます。このパッケージは、すでにデータベースにインストールされています。
表3-7に、コール対象の主要なファンクションを示します。
PL/SQLベースのWebアプリケーションのパフォーマンスを向上させるためにmod_plsqlをチューニングする場合、mod_plsqlの内部的な動作に精通していることが重要です。この項では、mod_plsqlのいくつかの機能についての概要を説明します。
この項の内容は、次のとおりです。
UNIXプラットフォームでは、mod_plsqlでのデータベース・サーバー接続プーリングのロジックは、例をあげることで最もよく説明できます。次の一般的な例を考えてみます。
httpdプロセスP1）が、リクエストR1の処理を開始します。
ステップ1〜10に示されたこの例で、重要な詳細は次のとおりです。
最悪のシナリオでは、mod_plsqlによってプールされるデータベース接続の合計数は、アクティブなDADの合計数と、1つのOracle HTTP Serverインスタンスに対して常に実行されているOracle HTTP Server（httpd）プロセスの数を掛けた数になります。Oracle HTTP Serverプロセスを大きい数に設定した場合、それに相当する数のデータベース・セッションを処理するように、バックエンド・データベースを設定する必要があります。この設定値には、バックエンド・データベースを使用するOracle HTTP Serverインスタンスの数を掛ける必要があります。
たとえば、Oracle HTTP Serverインスタンスが3つあり、それぞれ最大50のhttpdプロセスを作成するように設定されているとき、アクティブなDADが2つある場合、300（3*50*2）セッションを処理できるようにデータベースを設定する必要があります。この数には、他のWebアプリケーションが接続するのに必要なセッションは含まれていません。
Windowsプラットフォームでは、Oracle HTTP Serverはシングル・プロセスとして実行されます。このようなシステムでは、mod_plsqlの接続プールはスレッド間で共有され、データベース接続の合計数は、各DADに対する同時リクエストの数になります。データベース接続がスレッド間で共有されるため、4.3.4項「2リスナー方針」はWindowsシステムには適用されません。
プールされたデータベース・セッションは、次の状況下でクローズされます。
デフォルトでは、mod_plsqlによってプールされた各接続は、最大1000リクエストを処理するために使用されます。その後、データベース接続は停止され、次のmod_plsqlリクエストで再確立されます。これは、PL/SQLベースのWebアプリケーションまたはOracleのクライアント/サーバー側でのリソース・リークがシステムに悪影響を及ぼさないようにするために行われます。デフォルト値の1000は、DAD設定パラメータのPlsqlMaxRequestsPerSessionをチューニングして変更します。
デフォルトでは、mod_plsqlのクリーン・アップ・スレッドにより、プールされた各接続は、アイドル時間が15分を経過するとクリーン・アップされます。アイドル・セッションのタイムアウト値は、構成設定のPlsqlIdleSessionCleanupIntervalによって制御されます。サイトでmod_plsqlのコンテンツにアクセスする頻度が低いほど、アイドル・セッションのクリーン・アップはより頻繁に発生するため、ユーザーはあまり使用されないデータベース接続を確立することになります。このような状況では、パフォーマンスを向上させるためにPlsqlIdleSessionTimeoutIntervalのデフォルト設定を大きくすることを検討します。プールされたデータベース接続を長時間オープンにしておくことは、より多くのセッションで使用できるようにするために、データベースに余分な負荷が発生することを意味します。
UNIXシステムでは、Oracle HTTP Server構成パラメータのMaxRequestsPerChildによってOracle HTTP Serverプロセスが停止するタイミングが制御されます。たとえば、このパラメータが5000に設定されている場合、各Oracle HTTP Serverプロセスは、正確に5000リクエストを処理した後、停止します。また、Oracle HTTP Serverプロセスは、構成パラメータのMinSpareServers、MaxSpareServersおよびMaxClientsに基づいて、Oracle HTTP Serverのメンテナンスの一環として起動および停止することがあります。
Oracle HTTP Serverが正しく設定されていないと、Oracle HTTP Serverプロセスが頻繁に起動および停止するようになり、その結果、無駄なmod_plsqlの接続プーリングが発生します。最高のパフォーマンスにするには、各Oracle HTTP Serverプロセスが一定時間アクティブの状態を維持し、プロセスが停止しないように、Oracle HTTP Serverを設定します。
詳細は、3.11.3項「接続プールでの停止中のデータベース接続の検出」を参照してください。
mod_plsqlは、データベースへの接続のプールを保持し、確立されたデータベース接続を後続のリクエストに再利用します。接続プールのデータベース接続からレスポンスがない場合、mod_plsqlはそれを検出して、その停止中の接続を破棄し、新しいデータベース接続を後続のリクエストのために確立します。
mod_plsqlの停止中のデータベース接続の検出機能により、データベース・ノードまたはインスタンスが停止したときのランダムなエラーの発生がなくなります。また、この機能は、Real Application Cluster（RAC）のような高可用性の構成では非常に有効です。あるRACクラスタのノードが停止していると、mod_plsqlはそれを検出し、他のRACノードを使用してリクエストの処理をすぐに開始します。
デフォルトでは、RACノードまたはデータベース・インスタンスが停止し、mod_plsqlがノードへの接続をすでにプールしていた場合、プール内の停止中の接続を使用する最初のmod_plsqlリクエストは、HTTP-503の障害レスポンスがエンド・ユーザーに返されます。mod_plsqlはこの障害を使用して、プール内のすべての停止中の接続の検出および削除をトリガーします。mod_plsqlは、ノード障害が発生する前に作成されたすべての接続プールをpingします。このping操作は、プールされた接続を使用する次のリクエストの処理時に実行されます。ping操作が失敗した場合、そのデータベース接続は破棄され、新しい接続が確立されて処理されます。
|
関連項目
mod_plsqlリクエストがサーバーに対して作成されていない場合でも、mod_plsqlが停止中のデータベース接続をクローズする他の状況の詳細は、3.11.2項「プールされたデータベース・セッションのクローズ」を参照してください。 |
mod_plsqlでは、停止中のデータベース接続の検出機能をチューニングするための構成オプションを2つ提供しています。
mod_plsqlは、データベース・ノードの停止が原因と考えられる障害を検出すると接続を修正します。これは、PlsqlConnectionValidationパラメータによって制御されます。PlsqlConnectionValidationパラメータの詳細は、『Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。
PlsqlConnectionValidationパラメータがAutomaticまたはAlwaysValidateに設定されていると、mod_plsqlはプールされているデータベース接続をテストしようとします。
mod_plsqlが接続プール内の不良なデータベース接続をテストするための、タイムアウト期間を指定できます。これは、PlsqlConnectionTimeoutパラメータによって制御されます。このパラメータは、mod_plsqlが接続が使用できないと判断するまで、テスト・リクエストが完了するのを待つ最大時間を指定します。
PlsqlConnectionTimeoutパラメータの詳細は、『Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。
mod_plsqlには、次の制限があります。
PlsqlCacheMaxSizeおよびPlsqlCacheTotalSizeパラメータに使用できる最大値は、4294967296バイト（4GB）です。これより大きい値を指定すると、mod_plsqlで警告が発生し、内部で値が4GBに設定されます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|