ヘッダーをスキップ
Oracle® Fusion Middleware mod_plsqlユーザーズ・ガイド
11gリリース1(11.1.1)
B56249-03
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

3 mod_plsqlの概要

mod_plsqlは、Web上でのPL/SQLベースのデータベース・アプリケーションの配置をサポートします。mod_plsqlはOracle HTTP Serverの一部であり、Oracle Fusion Middlewareおよび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 Fusion Middleware PL/SQL Web Toolkitリファレンス』を参照してください。

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

3.1 クライアント・リクエストの処理

mod_plsqlは、データベースと通信を行うOracle HTTP Serverのプラグインです。これによって、ブラウザ・リクエストが、SQL*Net接続を通じてデータベース・ストアド・プロシージャ・コールにマッピングされます。通常、仮想パスの/plsで示されます。

次に、サーバーがクライアント・リクエストを受信するときのステップの概要(図3-1)を説明します。

図3-1 サーバーがクライアント・リクエストを受信する際の処理の概要

図3-1の説明は図の下のリンクをクリックしてください。
「図3-1 サーバーがクライアント・リクエストを受信する際の処理の概要」の説明

  1. Oracle HTTP Serverが、mod_plsqlで処理されるように構成されている仮想パスを含むリクエストを受信します。

  2. Oracle HTTP Serverは、そのリクエストをmod_plsqlにルーティングします。

  3. mod_plsqlは、DADに格納された設定情報を使用して、データベースに接続します。mod_plsqlは、リクエストをOracle Databaseに転送します。

  4. mod_plsqlは、コール・パラメータを準備して、アプリケーション内のPL/SQLプロシージャを実行します。

  5. PL/SQLプロシージャは、データベースからアクセスしたデータおよびPL/SQL Web Toolkitを使用して、HTMLページを生成します。

  6. レスポンスがmod_plsqlに返されます。

  7. Oracle HTTP Serverは、そのレスポンスをクライアント・ブラウザに送信します。

mod_plsqlから実行されたプロシージャは、HTTPレスポンスをクライアントに返します。この作業を簡単にするために、mod_plsqlにはPL/SQL Web Toolkitが含まれています。PL/SQL Web Toolkitには、OWAパッケージと呼ばれるパッケージのセットが含まれています。これらのパッケージをストアド・プロシージャ内で使用して、リクエスト情報の取得、HTMLタグの作成およびクライアントへのヘッダー情報の返信を行います。すべてのユーザーがアクセスできるように、このツールキットは共通スキーマにインストールしてください。

3.2 データベース・アクセス記述子(DAD)

各mod_plsqlリクエストは、データベース・アクセス記述子(DAD)に関連付けられています。DADは、データベース・アクセスに使用される設定値のセットです。DADでは次のような情報を指定します。

また、DADにはユーザー名とパスワードの情報を指定できます。指定がない場合には、URLの実行時にユーザー名とパスワードを入力するプロンプトが表示されます。


関連項目:

DADパラメータの説明とmod_plsql構成ファイルの概要は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

3.3 mod_plsqlの実行

mod_plsqlをWebブラウザで実行するには、次の形式でURLを入力します。

protocol://hostname[:port]/DAD_location/[[!][schema.][package.]proc_name[?query_string]]

表3-1に、mod_plsql実行時のパラメータを示します。

表3-1 mod_plsql実行時のパラメータ

パラメータ 説明

protocol

httpまたはhttpsのいずれか。SSLの場合は、httpsを使用します。

hostname

Webサーバーが稼働しているマシン。

port

(オプション)

Webサーバーがリスニングしているポート。指定しない場合、ポート80が使用されます。

DAD location

Webサーバーで設定したPL/SQLリクエストを処理するための仮想パス。DAD locationに使用できるのはASCII文字のみです。

!文字

(オプション)

柔軟なパラメータの受渡しスキームを使用することを示します。詳細は、3.6.2項「柔軟なパラメータの受渡し」を参照してください。

schema

(オプション)

データベース・スキーマ名。指定しない場合、package.proc_nameの名前解決は、URLリクエストを処理したデータベース・ユーザーに基づいて行われます。

package

(オプション)

PL/SQLストアド・プロシージャを含んだパッケージ。指定しない場合、プロシージャはスタンドアロンになります。

proc_name

実行するPL/SQLストアド・プロシージャ。ファンクションではなく、プロシージャを指定する必要があります。IN引数のみ使用可能です。

?query_string

(オプション)

ストアド・プロシージャのパラメータ。この文字列は、GETメソッドの書式に従います。たとえば、次のようになります。

  • 複数のパラメータはアンパサンド(&)で区切ります。渡される値内の空白文字はプラス(+)に置き換えられます。

  • HTMLフォームを使用して文字列を生成する場合(文字列を自分で生成するのではなく)、書式化は自動的に行われます。

  • HTTPリクエストがHTTPのPOSTメソッドを使用してデータをmod_plsqlに送信する場合もあります。詳細は、「POSTメソッド、GETメソッドおよびHEADメソッド」を参照してください。


例3-1例3-2および例3-3で、各種プロシージャがどのように実行されるかを説明します。

例3-1 引数をとらないプロシージャの実行

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プロシージャを実行します。

例3-2 引数をとるプロシージャの実行

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)をプロシージャに渡します。

例3-3 DAD設定に格納されているデフォルト・プロシージャの実行

http://www.acme.com:9000/pls/mydad 

この場合、www.acme.comで稼働し、ポート9000でリスニングしているWebサーバーがリクエストを処理します。Webサーバーは、リクエストを受信すると、/pls/mydadに関連付けられているDADを使用して、DADに設定されているデフォルト・プロシージャを実行します。たとえば、DAD /pls/mydadの構成パラメータPlsqlDefaultPagemyschema.mypackage.myprocに設定されている場合、プロシージャmyschema.mypackage.myprocがリクエストに対して実行されます。

この例では、DAD設定に指定されているmydadというDADのデフォルトのホームページが表示されます。

POSTメソッド、GETメソッドおよびHEADメソッド

HTTPプロトコルのPOSTメソッド、GETメソッドおよびHEADメソッドは、パラメータ・データをアプリケーションに渡す方法(通常は名前/値ペア形式)をブラウザに対して指示します。パラメータ・データはHTMLフォームによって生成されます。

mod_plsqlアプリケーションでは、いずれのメソッドも使用できます。各メソッドの保護レベルは、使用する転送プロトコル(HTTPまたはHTTPS)によって決定されます。


注意:

POSTデータは、HTMLフォーム上の入力フィールドの一部として生成されます。PL/SQLプロシージャまたはURLに、POST文字列を手動で作成しないでください。HTMLフォームの送信操作により、POSTリクエストが生成され、プロシージャに値が渡されます。

3.4 トランザクション・モード

プロシージャを実行するためにURLリクエストを処理した後、エラーがあれば、mod_plsqlによりロールバックが実行されます。そうでない場合は、コミットが実行されます。このメカニズムでは、トランザクションが複数のHTTPリクエストにまたがることはできません。この状態を保持しないモデルの場合、アプリケーションは、通常HTTP Cookieまたはデータベース表を使用して状態を維持します。

3.5 サポートされるデータ型

HTTPでサポートされるのはキャラクタ・ストリームのみのため、mod_plsqlではPL/SQLデータ型の次のサブセットがサポートされます。

レコードはサポートされません。

3.6 パラメータの受渡し

mod_plsqlは、次の処理をサポートしています。

3.6.1 名前によるパラメータの受渡し(パラメータのオーバーロード)

オーバーロードにより、名前が同じでパラメータの数、順序またはデータ型のファミリが異なる複数のサブプログラム(プロシージャまたはファンクション)を使用できます。オーバーロードされたサブプログラムをコールすると、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

オーバーロードとPL/SQL配列

パラメータ名が同じで、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に示すように、スカラー・データ型のプロシージャを実行します。

例3-4 URL送信によるスカラー・バージョンのプロシージャの実行

次のURLを送信して、スカラー・バージョンのプロシージャを実行します。

http://www.acme.com:9000/pls/mydad/my_proc?val=john

mod_plsqlは、valパラメータの値が複数存在するリクエストを受け取ると、例3-5に示すように、配列データ型のプロシージャを実行します。

例3-5 URL送信による配列バージョンのプロシージャの実行

次のURLを送信して、配列バージョンのプロシージャを実行します。

http://www.acme.com:9000/pls/mydad/my_proc?val=john&val=sally

確実に配列バージョンを実行できるようにする場合は、HTMLページでHIDDENフォーム・エレメントを使用してダミーの値を送信します。このダミーの値は、プロシージャ内でチェックされ、破棄されます。

3.6.2 柔軟なパラメータの受渡し

ユーザーがエレメントを必要な数だけ選択可能なHTMLフォームを使用できます。これらのエレメントにそれぞれ異なる名前が付いている場合は、オーバーロード・プロシージャを作成して可能な組合せを個別に処理する必要があります。または、問合せ文字列に含まれる名前が、ユーザーが選択するエレメントに関係なく確実に毎回一貫したものになるように、HIDDENフォーム・エレメントを挿入できます。mod_plsqlは、ユーザーが任意の数のエレメントを選択できるHTMLフォームを処理するために、柔軟なパラメータの受渡しをサポートすることで、この操作を容易にします。

URLベースのプロシージャの実行で柔軟なパラメータの受渡しを使用するには、URL内でプロシージャ名の先頭に感嘆符(!)を付加します。2パラメータまたは4パラメータを使用できます。2パラメータ・インタフェースによって、mod_plsqlのパフォーマンスが改善されます。4パラメータ・インタフェースは、互換性維持のためにサポートされています。

3.6.2.1 2パラメータ・インタフェース

procedure [proc_name] 
     (name_array IN [array_type],
     value_array IN  [array_type]);

表3-2に、2パラメータ・インタフェースのパラメータを示します。

表3-2 2パラメータ・インタフェースのパラメータ

パラメータ 説明

proc_name

(必須)

実行するPL/SQLプロシージャの名前。

name_array

問合せ文字列から取り出される名前(1から順番に索引付けされる)を送信された順序で示します。

value_array

問合せ文字列から取り出される値(1から順番に索引付けされる)を送信された順序で示します。

array_type

(必須)

varchar2型(owa.vc_arrなど)の表による任意のPL/SQL索引。


例3-6に、2パラメータ・インタフェースの使用例を示します。

例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')

注意:

このスタイルの柔軟なパラメータの受渡しを使用する場合は、パラメータname_arrayおよびvalue_arrayを使用してプロシージャを定義する必要があります。これらの引数のデータ型は、例に示したデータ型と一致する必要があります。

3.6.2.2 4パラメータ・インタフェース

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-3 4パラメータ・インタフェースのパラメータ

パラメータ 説明

proc_name

(必須)

実行するPL/SQLプロシージャの名前。

num_entries

問合せ文字列内の名前/値ペアの数。

name_array

問合せ文字列から取り出される名前(1から順番に索引付けされる)を送信された順序で示します。

value_array

問合せ文字列から取り出される値(1から順番に索引付けされる)を送信された順序で示します。

reserved

未使用。これは、将来使用するために予約されています。

array_type

(必須)

varchar2型(owa.vc_arrなど)の表による任意のPL/SQL索引。


例3-7に、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が実行され、次の引数が渡されます。

num_entries ==> 3 
name_array ==> ('x', 'y', 'x');
value_array ==> ('a', 'b', 'c')
reserved ==> ()

注意:

このスタイルの柔軟なパラメータの受渡しを使用する場合は、パラメータnum_entriesname_arrayvalue_arrayおよびreservedを使用してプロシージャを定義する必要があります。これらの引数のデータ型は、例に示したデータ型と一致する必要があります。

3.6.3 大きなパラメータの受渡し

スカラー引数として渡される値と、varchar2引数の索引付き表の要素として渡される値に使用できるサイズは、最大32KBです。

たとえば、柔軟なパラメータの受渡し(3.6.2項「柔軟なパラメータの受渡し」を参照)を使用する場合、URLのquery_string部分の名前または値は、それぞれ実行されるプロシージャのname_arrayまたはvalue_array引数のエレメントとして渡されます。これらの名前または値に使用できるサイズは、最大32KBです。

3.7 ファイルのアップロードとダウンロード

mod_plsqlでは、次の機能を提供します。

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

3.7.1 ドキュメント表の定義

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_typeがLONG RAWの場合content_column_nameはCONTENTにする必要があります。

  • content_column_typeがBLOBの場合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 ;
);

3.7.1.1 CONTENT列のセマンティクス

表の内容は、CONTENT列に格納されます。ドキュメント表には、複数のCONTENT列を含めることが可能です。ただし、ドキュメント表の各行について、使用されるCONTENT列は1つのみです。その他のCONTENT列はNULLに設定されます。

3.7.1.2 CONTENT_TYPE列のセマンティクス

CONTENT_TYPE列は、ドキュメントが格納されているCONTENT列を追跡するために使用されます。ドキュメントがアップロードされると、mod_plsqlにより、この列の値が型名に設定されます。

たとえば、ドキュメントがBLOB_CONTENT列にアップロードされた場合、ドキュメントのCONTENT_TYPE列には文字列BLOBが設定されます。

3.7.1.3 LAST_UPDATED列のセマンティクス

LAST_UPDATED列には、ドキュメントの作成日時または最終更新日時が反映されます。ドキュメントがアップロードされると、mod_plsqlにより、ドキュメントのLAST_UPDATED列にデータベース・サーバーの時間が設定されます。

その後、アプリケーションがドキュメントの内容または属性を変更する場合、LAST_UPDATEDの時間も更新されるようにする必要があります。

mod_plsqlでは、LAST_UPDATED列を使用して、HTTPクライアント(ブラウザ)がドキュメントのキャッシュ済バージョンを使用できるかどうかをチェックし、HTTPクライアントに結果を知らせます。これにより、ネットワークの通信量が削減され、サーバーのパフォーマンスが改善されます。

3.7.1.4 DAD_CHARSET列のセマンティクス

DAD_CHARSET列は、ファイルのアップロード時のキャラクタ・セット設定を追跡します。この列は、今後使用するために予約されています。

3.7.2 以前のスタイルのドキュメント表の定義

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

3.7.3 ドキュメントのアップロード/ダウンロードの構成パラメータ

DADの次の設定パラメータが、ドキュメントのアップロードまたはダウンロード操作に影響します。

例3-8に、構成パラメータの使用例とその結果を示します。

例3-8 ドキュメントのアップロード/ダウンロードのパラメータ

DADでこれらのパラメータが次のように設定されているとします。

PlsqlDocumentTablename   scott.my_document_table
PlsqlUploadAsLongRaw   html
PlsqlDocumentPath   docs
PlsqlDocumentProcedure   scott.my_doc_download_procedure

この場合は次のようになります。

  • mod_plsqlは、scottスキーマのmy_document_tableデータベース表からデータを取得するか、この表にデータを格納します。

  • .htmlを除くすべてのファイル拡張子は、ドキュメント表にBLOBとしてアップロードされます。.html拡張子が付いたファイルはすべてLong Rawとしてアップロードされます。

  • DAD locationの直後にdocsキーワードを含むすべてのURLでは、scott.my_doc_download_procedureプロシージャが実行されます。

    通常、このプロシージャはwpg_docload.download_fileをコールして、URL指定に基づく名前を持ったファイルのダウンロードを開始します。

次に前述の構成の単純な例を示します。

http://www.acme.com:9000/pls/dad/docs/index.html

この場合は、scott.my_document_tableデータベース表のLong Raw列からindex.htmlファイルがダウンロードされます。アプリケーション・プロシージャは、開始するファイルのダウンロードを完全に制御し、ファイル・レベルのアクセス制御とバージョニングを実装する、より複雑なPlsqlDocumentProcedureを柔軟に定義します。


注意:

アプリケーション定義プロシージャscott.my_doc_download_procedureは引数なしで定義し、CGI環境変数に応じてリクエストを処理する必要があります。

3.7.3.1 PlsqlDocumentTablename

PlsqlDocumentTablenameパラメータは、このDADによってファイルがアップロードされたときにドキュメントを格納する表を指定します。

構文:

PlsqlDocumentTablename  [document_table_name]

PlsqlDocumentTablename  my_documents

または

PlsqlDocumentTablename  scott.my_document_table

3.7.3.2 PlsqlDocumentPath(ドキュメント・アクセス・パス)

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]

3.7.3.3 PlsqlDocumentProcedure(ドキュメント・アクセス・プロシージャ)

PlsqlDocumentProcedureプロシージャは、アプリケーション指定のプロシージャです。このプロシージャはパラメータがなく、ドキュメント・アクセス・パスを持つURLリクエストを処理します。ドキュメント・アクセス・プロシージャは、ファイルをダウンロードするために、wpg_docload.download_file(filename)をコールします。ドキュメント・アクセス・プロシージャは、URL指定に基づいてファイル名を認識します。たとえば、アプリケーションでこれを使用して、ファイル・レベルのアクセス制御やバージョン管理を実装することが可能です。このようなアプリケーションの例は、3.7.7項「ファイルのダウンロード」にあります。

構文:

PlsqlDocumentProcedure  [document_access_procedure_name]

例3-9に、PlsqlDocumentProcedureプロシージャの使用例を示します。

例3-9 PlsqlDocumentProcedure

PlsqlDocumentProcedure  my_access_procedure

または

PlsqlDocumentProcedure  scott.my_pkg.my_access_procedure

3.7.3.4 PlsqlUploadAsLongRaw

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プロシージャの使用例を示します。

例3-10 PlsqlUploadAsLongRaw

PlsqlUploadAsLongRaw  html 
PlsqlUploadAsLongRaw  txt
PlsqlUploadAsLongRaw  *

3.7.4 ファイルのアップロード

クライアント・マシンからデータベースにファイルを送信する場合は、次に示す内容を含んだHTMLページを作成します。

  • enctype属性にmultipart/form-dataが設定され、action属性に「アクション・プロシージャ」と呼ばれるmod_plsqlプロシージャ・コールが関連付けられているFORMタグ。

  • type属性とname属性にfileが設定されたINPUTエレメント。INPUT type="file"エレメントを使用すると、ユーザーはファイル・システムのファイルを参照して、そこからファイルを選択できます。

ユーザーが「Submit」ボタンをクリックすると、次のイベントが発生します。

  1. ブラウザは、ユーザーが指定したファイルとその他のフォーム・データをサーバーにアップロードします。

  2. mod_plsqlは、ファイルの内容をデータベースのドキュメント格納表内に格納します。表の名前は、PlsqlDocumentTablename DAD設定から取得されます。

  3. FORMのaction属性で指定したアクション・プロシージャが、ファイルのアップロードを行わずにmod_plsqlプロシージャを実行する場合と同じように実行されます。


    注意:

    HTMLドキュメントの解析は、mod_plsqlでは非推奨となりました。以前は、HTMLファイルのアップロード時にmod_plsqlを使用してその内容が解析され、HTMLドキュメントが参照している他のファイルが識別されていました。その後、この情報が表に格納されていました。表の名前は、ドキュメント表の名前にpartを追加したものが使用されていました。この機能は、カスタマにとって有用でないことが判明したため、リリース9.0.4の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="filename"><br>
      <p><INPUT type="submit">
   </FORM>
   </body>
</html>

ユーザーがフォームの「Submit」ボタンをクリックすると、次の処理が実行されます。

  1. ブラウザにより、INPUT type="file"エレメントにリストされたファイルがアップロードされます。

  2. 次に、write_infoプロシージャが実行されます。

  3. このプロシージャは、フォームのフィールドの情報をデータベース内の表に書き込み、ページをユーザーに返します。


    注意:

    アクション・プロシージャでは、ユーザーにレスポンスを返す必要はありませんが、次に示すように、送信が成功したか失敗したかをユーザーに知らせるようにすることをお薦めします。

    procedure write_info (
         who         in varchar2,
         description in varchar2,
         filename        in varchar2) as
    begin
         insert into myTable values (who, description, filename);
         htp.htmlopen;
         htp.headopen;
         htp.title('Filename Uploaded');
         htp.headclose;
         htp.bodyopen;
         htp.header(1, 'Upload Status');
         htp.print('Uploaded ' || filename || ' successfully');
         htp.bodyclose;
         htp.htmlclose;
    end;
    

名前の競合の可能性を低減するために、ブラウザから取得したファイル名の先頭に、生成されたディレクトリ名が付加されます。フォームで指定されたアクション・プロシージャにより、この名前が変更されます。このため、たとえば/private/minutes.txtがアップロードされた場合、mod_plsqlによって表に格納される名前は、F9080/private/minutes.txtとなります。アプリケーションは、コールしたストアド・プロシージャの中で、この名前を変更できます。たとえば、アプリケーションにより、名前をscott/minutes.txtに変更できます。


関連項目:

RFC 1867『Form-Based File Upload in HTML』(IETF)

3.7.5 アップロード・ファイルの属性(MIMEタイプ)の指定

ストアド・プロシージャは、アップロード・ファイルの名前を変更する以外にも、他のファイル属性を変更できます。たとえば、3.7.4項「ファイルのアップロード」に示した例のフォームでは、アップロードされるドキュメントのMultipurpose Internet Mail Extension(MIME)タイプをユーザーが入力可能なフィールドとして表示できます。

MIMEタイプは、write_infoのパラメータとして受信できます。その場合、ドキュメント表には、ファイルのアップロード時にmod_plsqlがマルチパート・フォームから解析したデフォルトのMIMEタイプではなく、そのドキュメントのMIMEタイプが格納されます。

3.7.6 複数のファイルのアップロード

1回の送信で複数のファイルを送信する場合は、アップロード・フォームに適切な"name"属性がある複数の<INPUT type="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.7.7 ファイルのダウンロード

ファイルをデータベースにアップロードした後、次に説明する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でPlsqlDocumentPathdocsとして、PlsqlDocumentProceduremyschema.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;
    
  • バイナリ・ラージ・オブジェクト(BLOB)のダイレクト・ダウンロード・メカニズムを使用して、BLOBをデータベース表からダウンロードします。このためには、次に示すように、標準のHTTPヘッダー(MIMEタイプやコンテンツ長など)を返すPL/SQLプロシージャをコールし、wpg_docload.download_file(blob_name)を起動してBLOBのblob_nameをダウンロードします。

    1. wpg_docload.download_file(blob)をコールするストアド・プロシージャを作成します。blobはBLOBデータ型です。mod_plsqlにはBLOBの内容に関する情報が含まれていないため、情報を入力する必要があります。

    2. Content-Typeおよびその他のヘッダーを設定します。

      次の例では、プロシージャは引数の名前を使用して表からBLOBを選択し、BLOBのダイレクト・ダウンロードを開始します。

      create or replace procedure download_blob(name in varchar2) is
      myblob blob; 
      begin
      
      • name引数を使用して、mytableからBLOBを選択します。

        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;
        
      • BLOBのダイレクト・ダウンロードを開始します。

        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ヘッダーを追加するために使用されます。


注意:

wpg_docload.download_file APIをプロシージャからコールするたびに、ファイル・ダウンロード操作がmod_plsqlにより開始されます。このような操作では、プロシージャによって生成される他のHTMLコンテンツは、ブラウザには渡されません。

マルチバイト・キャラクタを使用するドキュメントのダウンロード

Windowsプラットフォームでmod_plsqlを使用しており、マルチバイト・キャラクタ・セット(日本語または韓国語)の一部として特殊文字0x5cを含むマルチバイト・データベースに対して実行している場合、ファイルdads.confを変更して、アプリケーションへのアクセスに使用されるDADを編集する必要があります。このためには、次の手順を実行します。

  1. ORACLE_INSTANCE\config\OHS\ohs1\mod_plsql\dads.confファイルを開きます。

  2. アプリケーションのアクセスに使用されるDADを探します。

  3. WindowsFileConversion Offの行をこのDADエントリに追加します。

  4. ファイルを保存します。

  5. Oracle HTTP Serverを再起動します。

DAD設定を更新しないと、ファイル名に0x5cが含まれるドキュメントのダウンロード時に障害が発生します。たとえば、次のようになります。

  • Oracle Portalで、次のダウンロード・エラーが示されます。

    Error: Document not found (WWC-46000)
    
  • ユーザー独自のPL/SQLアプリケーションに対してmod_plsqlを使用すると、ファイルのダウンロードで次のエラーが発生します。

    HTTP-404 Not Found
    

3.8 パスのエイリアシング(ダイレクト・アクセスURL)

パスのエイリアシングにより、mod_plsqlを使用するアプリケーションは、単純なURLによるアプリケーション内のオブジェクトへの直接参照を提供できます。この機能は、ドキュメント・ダウンロード機能の提供方法を汎用化するものです。パスのエイリアシングには、DADの次の設定パラメータを使用します。

たとえば、DADでこれらのパラメータが次のように設定されているとします。

PlsqlPathAlias   myalias 
PlsqlPathAliasProcedure   scott.my_path_alias_procedure 

この場合、DAD locationの直後にmyaliasキーワードを含むすべてのURLで、scott.my_path_alias_procedureプロシージャが実行されます。このプロシージャは、URL指定に基づいて適切なレスポンスを開始できます。


注意:

アプリケーション定義プロシージャscott.my_path_alias_procedureは、varchar2型のp_pathという引数を1つとるように定義する必要があります。この引数は、PlsqlPathAliasに使用されているキーワードに続くすべてを受け取ります。

たとえば、前述の構成で次のURLがあるとします。

http://www.acme.com:9000/pls/dad/myalias/MyFolder/MyItem

このURLにより、scott.my_path_alias_procedureプロシージャはMyFolder/MyItem引数を受け取ります。


3.9 Common Gateway Interface(CGI)環境変数

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には大/小文字の区別があります。

3.9.1 CGI環境変数の追加およびオーバーライド

PlsqlCGIEnvironmentList DADパラメータは、1行に1つのエントリがある、名前/値ペアのリストです。任意の環境変数のオーバーライドや、新規の環境変数の追加ができます。名前が付属の環境変数(3.9項「Common Gateway Interface(CGI)環境変数」のリストを参照)の1つである場合、その環境変数は指定した値でオーバーライドされます。名前が付属の環境変数のリストにない場合は、パラメータで指定された名前および値と同じ新規の環境変数がリストに追加されます。


注意:

mod_plsqlの設定ファイルについては、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

パラメータの値が指定されていない場合は、Oracle HTTP Serverから値が取得されます。Oracle HTTP Serverの場合は、次のように指定してCGI環境変数のDOCUMENT_ROOTを渡すことができます。

PlsqlCGIEnvironmentList DOCUMENT_ROOT

この設定パラメータから渡された新規の環境変数は、owa_util.get_cgi_envインタフェースを経由してPL/SQLアプリケーションで使用できます。

例3-11に、環境変数のオーバーライドが指定されたPlsqlCGIEnvironmentListの使用例を示します。

例3-11 環境変数のオーバーライドが指定されたPlsqlCGIEnvironmentList

PlsqlCGIEnvironmentList SERVER_NAME=myhost.mycompany.com
PlsqlCGIEnvironmentList REMOTE_USER=testuser

この例では、CGI環境変数のSERVER_NAMEとREMOTE_USERが付属の環境変数リストに含まれているため、これらの環境変数が指定の値にオーバーライドされます。

例3-12に、新規の環境変数が指定されたPlsqlCGIEnvironmentListの使用例を示します。

例3-12 新規の環境変数が指定されたPlsqlCGIEnvironmentList

PlsqlCGIEnvironmentList MYENV_VAR=testing
PlsqlCGIEnvironmentList SERVER_NAME=
PlsqlCGIEnvironmentList REMOTE_USER=user2

この例では、SERVER_NAME変数とREMOTE_USER変数がオーバーライドされます。SERVER_NAME変数は、値が指定されていないため、削除されます。MYENV_VARという新規の環境変数は、付属の環境変数のリストに含まれていないため追加されます。この環境変数には、「testing」という値が割り当てられます。

3.9.2 PlsqlNLSLanguage

mod_plsqlでは、PlsqlNLSLanguageのDADレベルの設定により、グローバリゼーション・サポート設定が制御されます。DADレベルでPlsqlNLSLanguageが設定されていない場合、グローバリゼーション・サポート設定にはOracleのNLS_LANGパラメータの環境設定が使用されます。このパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。

3.9.2.1 REQUEST_CHARSET CGI環境変数

CGI環境変数REQUEST_CHARSETは、PlsqlNLSLanguageの設定に基づいて設定されます。DADレベルでPlsqlNLSLanguageが設定されていない場合、グローバリゼーション・サポート設定にはOracleのNLS_LANGパラメータの環境設定が使用されます。

PL/SQLアプリケーションは、ファンクション・コールによってこの情報にアクセスできます。たとえば、次のようになります。

owa_util.get_cgi_env('REQUEST_CHARSET');

3.9.2.2 REQUEST_IANA_CHARSET CGI環境変数

これは、CGI環境変数REQUEST_CHARSETに相当するIANA(Internet Assigned Number Authority)の環境変数です。IANAは、インターネット上のキャラクタ・セットの標準をグローバルに調整する機関です。

PL/SQLアプリケーションは、ファンクション・コールによってこの情報にアクセスできます。たとえば、次のようになります。

owa_util.get_cgi_env('REQUEST_IANA_CHARSET');

3.10 PL/SQLベースのWebアプリケーションでのキャッシングの使用

キャッシングを使用すると、PL/SQLベースのWebアプリケーションのパフォーマンスを向上させることができます。パフォーマンスを向上させるために、中間層のPL/SQLプロシージャによって生成されたWebコンテンツをキャッシュして、データベースのワークロードを減少させることができます。

この項では、次のようなキャッシングの方式について説明します。

これらの方式およびレベルは、PL/SQL Web Toolkitに含まれるowa_cacheパッケージを使用して実装されます。


関連項目:

『Oracle Fusion Middleware PL/SQL Web Toolkitリファレンス』

3.10.1 検証方式の使用

通常、検証方式では、ページが最後に提示されてから変更があったかどうかをサーバーに確認します。ページが変更されていない場合、キャッシュされたページがユーザーに提示されます。ページが変更されている場合、新しいコピーを取得してユーザーに提示した後、それをキャッシュします。

検証方式を使用する方法には、Last-Modified方法およびEntity Tag方法の2つがあります。次の2つの項では、これらの方式がHTTPプロトコルでどのように使用されるかを示します。PL/SQL GatewayではHTTPプロトコルを使用しませんが、多くの同じ原則が使用されます。

3.10.1.1 Last-Modified方法

WebページがHTTPプロトコルを使用して生成されると、そのページにはLast-Modifiedレスポンス・ヘッダーが含まれます。このヘッダーは、リクエストされたコンテンツの日付(サーバーを基準とする)を示しています。ブラウザは、この日付情報をコンテンツとともに保存します。後続のリクエストがWebページのURLに対して作成されると、ブラウザは次の処理を行います。

  1. キャッシュされているバージョンがあるかどうかを確認します。

  2. 日付情報を抽出します。

  3. リクエスト・ヘッダーのIf-Modified-Sinceを生成します。

  4. リクエストをサーバーに送信します。

キャッシュ対応のサーバーは、If-Modified-Sinceヘッダーを探し、それをコンテンツの日付と比較します。この2つが一致する場合は、「HTTP/1.1 304 Not Modified」などのHTTPレスポンス・ステータス・ヘッダーが生成され、コンテンツは返されません。このステータス・コードを受け取ると、キャッシュ・エントリは有効であるため、ブラウザはそれを再利用できます。

この2つが一致しない場合は、「HTTP/1.1 200 OK」などのHTTPレスポンス・ヘッダーが生成され、新しいコンテンツが、新しいLast-Modifiedレスポンス・ヘッダーとともに返されます。このステータス・コードを受け取ると、ブラウザはキャッシュ・エントリを新しいコンテンツおよび新しい日付情報で置き換える必要があります。

3.10.1.2 Entity Tag方法

HTTPプロトコルによって提供されるもう1つの検証方法は、ETag(Entity Tag)レスポンス/リクエスト・ヘッダーです。このヘッダーの値は、ブラウザに対して不明瞭な文字列です。サーバーは、この文字列をアプリケーションのタイプに基づいて生成します。この方法は、日付値のみを含めることができるIf-Modified-Sinceヘッダーよりも一般的な検証方法です。

ETag方法は、Last Modified方法とよく似ています。サーバーは、レスポンス・ヘッダーの一部としてETagを生成します。ブラウザは、この不明瞭なヘッダー値を返されたコンテンツとともに格納します。このコンテンツに対する次のリクエストを受信すると、ブラウザは、格納された不明瞭な値をIf-Matchヘッダーに設定してサーバーに渡します。サーバーがこの不明瞭な値を生成しているため、何をブラウザに返すかを判別できます。その他は、前述したLast-Modified検証方法とまったく同じです。

3.10.1.3 mod_plsqlでの検証方式の使用

HTTP検証キャッシングをフレームワークとして使用すると、mod_plsqlの検証モデルは次のようになります。

処理されるコンテンツを制御するPL/SQLベースのWebアプリケーションでは、この種のキャッシングを使用する必要があります。この方式を使用すると、適度にパフォーマンスが改善されます。たとえば、常に変わる動的コンテンツを処理するWebアプリケーションがこれに該当します。この場合、Webアプリケーションには、処理対象に対する完全な制御が必要です。検証キャッシングでは、キャッシュされたコンテンツが古いものか、またはブラウザに返された後のものであるかをWebアプリケーションに常に確認します。

図3-2は、mod_plsqlで検証方式が使用される仕組みを表したものです。

  1. Oracle HTTP Serverがクライアント・サーバーからPL/SQLプロシージャ・リクエストを受信します。Oracle HTTP Serverは、そのリクエストをmod_plsqlにルーティングします。

  2. mod_plsqlはリクエストを準備します。

  3. mod_plsqlはWebアプリケーションでPL/SQLプロシージャを起動し、通常のCommon Gateway Interface(CGI)環境変数をWebアプリケーションに渡します。

  4. PL/SQLプロシージャは、返すためのコンテンツを生成します。PL/SQLプロシージャが生成されたコンテンツをキャッシュ可能であると判断した場合、PL/SQL Web Toolkitのowa_cacheプロシージャをコールし、タグおよびキャッシュ・レベルを設定します。

    owa_cache.set_cache(p_etag, p_level);
    

    表3-4に、検証モデルのパラメータを示します。

表3-4 検証モデルのパラメータ

パラメータ 説明

set_cacheプロシージャ

返されたコンテンツがキャッシュできることをmod_plsqlに通知するためのヘッダーを設定します。その後、コンテンツがブラウザに返される際に、mod_plsqlは、タグおよびキャッシング・レベル情報とともにコンテンツをローカル・ファイル・システムにキャッシュします。

p_etag

コンテンツをタグ付けするためにプロシージャが生成する文字列。

p_level

キャッシング・レベル: SYSTEM(システム・レベルの場合)またはUSER(ユーザー・レベルの場合)。


  1. HTMLがmod_plsqlに返されます。

  2. mod_plsqlは、次のリクエストのために、キャッシュ可能なコンテンツをファイル・システムに格納します。

  3. Oracle HTTP Serverは、そのレスポンスをクライアント・ブラウザに送信します。

3.10.1.4 検証方式を使用した2番目のリクエスト

mod_plsqlの検証方式を使用し、クライアント・ブラウザによって、同じPL/SQLプロシージャに対する2番目のリクエストが作成されます。

図3-3に、検証方式を使用した2番目のリクエストを示します。

図3-3 検証方式 - 2番目のリクエスト

図3-3の説明は図の下のリンクをクリックしてください。
「図3-3 検証方式 - 2番目のリクエスト」の説明

  1. mod_plsqlは、リクエストに対してキャッシュされたコンテンツがあることを検出します。

  2. mod_plsqlは、(最初のリクエストからの)同じタグおよびキャッシング・レベル情報をCGI環境変数の一部としてPL/SQLプロシージャに転送します。

  3. PL/SQLプロシージャは、これらのキャッシングCGI環境変数を使用して、コンテンツが変更されているかどうかを確認します。そのために、PL/SQL Web Toolkitの次のowa_cacheファンクションをコールします。

    owa_cache.get_etag;
    owa_cache.get_level;
    

    これらのowaファンクションが、タグおよびキャッシング・レベルを取得します。

  4. Webアプリケーションは、このキャッシング情報をmod_plsqlに送信します。

  5. この情報に基づいて、コンテンツを再生成する必要があるか、またはキャッシュから取得できるかを判別します。

    1. コンテンツが同じである場合は、プロシージャはowa_cache.set_not_modifiedプロシージャをコールし、コンテンツを生成しません。このため、mod_plsqlではキャッシュされたコンテンツを使用します。このキャッシュされたコンテンツは、ブラウザに直接返されます。

    2. コンテンツに変更があった場合は、新規のタグおよびキャッシュ・レベルとともに新規コンテンツが生成されます。mod_plsqlでは、キャッシュ内の古いコピーが新規コピーで置換され、タグおよびキャッシュ・レベル情報が更新されます。新しく生成されたコンテンツが、ブラウザに返されます。

3.10.2 期限方式の使用

検証モデルでは、mod_plsqlは、キャッシュからコンテンツを提供できるかどうかを常にPL/SQLプロシージャに確認します。期限モデルでは、プロシージャはコンテンツの有効期間をあらかじめ設定します。そのため、mod_plsqlは、プロシージャに確認することなくキャッシュからコンテンツを提供できます。この方式では、データベースとのやり取りが必要ないため、パフォーマンスが一層向上します。

このキャッシング方式を使用すると、最高のパフォーマンスが得られます。PL/SQLベースのWebアプリケーションにおいて、古いコンテンツの提供が問題にならない場合に使用します。たとえば、ニュースを毎日生成するアプリケーションがこれに該当します。ニュースは24時間有効に設定できます。24時間以内であれば、アプリケーションとやり取りせずにキャッシュされたコンテンツが提供されます。これは、基本的にファイルの提供と同じです。24時間を経過すると、mod_plsqlは再度新しいコンテンツをアプリケーションから取得します。

検証モデルで説明したものと同じシナリオを考えてみます。ただし、プロシージャではキャッシングに期限モデルを使用します。

図3-4は、mod_plsqlで期限方式が使用される仕組みを表したものです。

  1. Oracle HTTP Serverがクライアント・サーバーからPL/SQL Server Pageリクエストを受信します。Oracle HTTP Serverは、そのリクエストをmod_plsqlにルーティングします。

  2. mod_plsqlは、リクエストをOracle Databaseに転送します。

  3. mod_plsqlはアプリケーションでPL/SQLプロシージャを起動し、通常のCommon Gateway Interface(CGI)環境変数をアプリケーションに渡します。

  4. PL/SQLプロシージャは、返すためのコンテンツを生成します。PL/SQLプロシージャが生成されたコンテンツをキャッシュ可能であると判断した場合、PL/SQL Web Toolkitのowa_cacheプロシージャをコールし、有効期間およびキャッシュ・レベルを設定します。

    owa_cache.set_expires(p_expires, p_level);
    

表3-5に、期限モデルのパラメータを示します。

表3-5 期限モデルのパラメータ

パラメータ 説明

set_expiresプロシージャ

期限キャッシングを使用していることをmod_plsqlに通知するためのヘッダーを設定します。その後、mod_plsqlは、有効期間およびキャッシング・レベル情報とともにコンテンツをファイル・システムにキャッシュします。

p_expires

コンテンツが有効な分数。

p_level

キャッシング・レベル。


  1. HTMLがmod_plsqlに返されます。

  2. mod_plsqlは、次のリクエストのために、キャッシュ可能なコンテンツをファイル・システムに格納します。

  3. Oracle HTTP Serverは、そのレスポンスをクライアント・ブラウザに送信します。

期限方式を使用した2番目のリクエスト

前述の同じ期限モデルを使用し、クライアント・ブラウザによって、同じPL/SQLプロシージャに対する2番目のリクエストが作成されます。

図3-5に、期限方式を使用した2番目のリクエストを示します。

図3-5 期限方式 - 2番目のリクエスト

図3-5の説明は図の下のリンクをクリックしてください。
「図3-5 期限方式 - 2番目のリクエスト」の説明

  1. mod_plsqlは、期限ベースの、キャッシュされたコンテンツのコピーがあることを検出します。

  2. mod_plsqlは、現在の時刻とこのキャッシュ・ファイルが作成された時刻の差を取得してコンテンツの有効性を確認します。

    1. この差が有効期間内にある場合は、キャッシュされたコピーはまだ新しいものであるため、データベースとやり取りせずに使用されます。このキャッシュされたコンテンツは、ブラウザに直接返されます。

    2. この差が有効期間内にない場合は、キャッシュされたコピーは古くなっています。mod_plsqlは、PL/SQLプロシージャを起動して、新しいコンテンツを生成します。次に、プロシージャが期限ベースのキャッシングを再度使用するかどうかを決定します。使用する場合は、この新しいコンテンツの有効期間も決定します。新しく生成されたコンテンツが、ブラウザに返されます。

3.10.3 PL/SQLベースのWebアプリケーションでのシステム・レベルおよびユーザー・レベルのキャッシング

PL/SQLプロシージャは、生成されたコンテンツがシステム・レベルのコンテンツか、ユーザー・レベルのコンテンツかを判断します。これにより、複数のユーザーが同じコンテンツを参照している場合、PL/SQL Gatewayキャッシュによる重複ファイルの格納を減らすことができます。判断は、次の基準で行われます。

  • システム・レベル・コンテンツの場合、プロシージャは、文字列SYSTEMをキャッシング・レベル・パラメータとしてowa_cacheファンクションに渡します(検証モデルの場合はset_cache、期限モデルの場合はset_expires)。これは、キャッシュを共有するすべてのユーザーに対して行われます。

    システム・レベル・キャッシングを使用すると、ファイル・システムの領域とシステム内のすべてのユーザーに費やす時間の両方を節約できます。たとえば、そのWebアプリケーションを使用しているすべてのユーザーを対象としたコンテンツを生成するWebアプリケーションがこれに該当します。システム・レベル設定でコンテンツをキャッシングすると、コンテンツのコピーは1つのみファイル・システムにキャッシュされます。さらに、コンテンツはキャッシュからディレクトリに提供されるため、そのシステムのすべてのユーザーにメリットがあります。

  • ユーザー・レベル・コンテンツの場合、プロシージャは、文字列USERをキャッシング・レベルのパラメータとして渡します。これは、ログインしている特定のユーザーに対して行われます。格納されるキャッシュはそのユーザー独自のものです。そのユーザーのみがキャッシュを使用できます。ユーザーのタイプは、認証モードによって決まります。様々なユーザーのタイプは、表3-6を参照してください。

表3-6 認証モードにより決定されるユーザーのタイプ

認証モード ユーザーのタイプ

Single Sign-On(SSO)

軽量ユーザー

Basic

データベース・ユーザー

カスタム

リモート・ユーザー


たとえば、PL/SQLベースのWebアプリケーションをカスタマイズしているユーザーがいない場合、出力はシステム・レベル・キャッシュに格納できます。システムのすべてのユーザーに対してキャッシュ・コピーは1つしかありません。複数のユーザーがキャッシュを使用できるため、ユーザー情報は使用されません。

ただし、ユーザーがアプリケーションをカスタマイズしている場合、ユーザー・レベル・キャッシュはそのユーザーに対してのみ格納されます。他のユーザーはすべて、引き続きシステム・レベル・キャッシュを使用します。ユーザー・レベル・キャッシュ・ヒットにおいては、ユーザー情報が基準となります。ユーザー・レベル・キャッシュは、常にシステム・レベル・キャッシュをオーバーライドします。


関連項目:

認証モードの詳細は、2.2項「mod_plsqlを使用したユーザー認証」を参照してください。

PL/SQL Web Toolkitのファンクション(owa_cacheパッケージ)

検証方式または期限方式のどちらを使用するのかによって、コールするowa_cacheのファンクションが決まります。

owa_cacheパッケージには、特別なキャッシング・ヘッダーと環境変数を設定および取得するプロシージャが含まれます。開発者は、これらのプロシージャを使用すると、PL/SQL Gatewayキャッシュをより簡単に使用できます。このパッケージは、すでにデータベースにインストールされています。

表3-7に、コール対象の主要なファンクションを示します。

表3-7 主要なowa_cacheのファンクション

owaファンクション 目的

owa_cache.set_cache (p_etag IN varchar2, p_level IN varchar2)

検証モデル: ヘッダーを設定します。

  • p_etagパラメータは、生成されたコンテンツをタグ付けします。

  • p_levelパラメータは、使用するキャッシング・レベルを表します。

owa_cache.set_not_modified

検証モデル: キャッシュされたコンテンツを使用するようにmod_plsqlに通知するためのヘッダーを設定します。検証ベースのキャッシュ・ヒットが発生する場合のみ使用されます。

owa_cache.get_level

検証モデル: キャッシング・レベルのUSERまたはSYSTEMを取得します。キャッシュがヒットしない場合はNULLを返します。

owa_cache.get_etag

検証モデル: キャッシュされたコンテンツと関連付けられているタグを取得します。キャッシュがヒットしない場合はNULLを返します。

owa_cache.set_expires(p_expires IN number, p_level IN varchar2)

期限モデル: ヘッダーを設定します。

  • p_expiresパラメータは、コンテンツが有効な分数を表します。

  • p_levelパラメータは、使用するキャッシング・レベルを表します。


3.11 mod_plsqlのパフォーマンス・チューニングの領域

PL/SQLベースのWebアプリケーションのパフォーマンスを向上させるためにmod_plsqlをチューニングする場合、mod_plsqlの内部的な動作に精通していることが重要です。この項では、mod_plsqlのいくつかの機能について概要を説明します。

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

3.11.1 mod_plsqlの接続プーリング

UNIXプラットフォームでは、mod_plsqlでのデータベース・サーバー接続プーリングのロジックは、例をあげることで最もよく説明できます。次の一般的な例を考えてみます。

  1. Oracle HTTP Serverリスナーが起動されます。mod_plsqlによって保持されている接続プールにデータベース接続はありません。

  2. ブラウザが、データベース・アクセス記述子(DAD)D1に対してmod_plsqlリクエスト(R1)を作成します。

  3. Oracle HTTP Serverプロセスの1つ(httpdプロセスP1)が、リクエストR1の処理を開始します。

  4. プロセスP1のmod_plsqlが接続プールを確認し、このユーザー・リクエストに対するデータベース接続がプールにないことがわかります。

  5. DAD D1の情報に基づいて、プロセスP1のmod_plsqlが、新しいデータベース接続をオープンし、PL/SQLリクエストを処理して、プールにそのデータベース接続を追加します。

  6. この時点から、DAD D1のプロセスP1に対する後続のすべてのリクエストは、mod_plsqlによってプールされたデータベース接続を使用できます。


    注意:

    11g UNIXリリースでは、Oracle HTTP Serverはプロセスごとの複数のスレッドをサポートしています。複数の同時mod_plsqlリクエストが1つのOracle HTTP Serverプロセスで処理される場合、mod_plsqlは、必要に応じて同時mod_plsqlリクエストを処理するために追加のデータベース接続をオープンします。

  7. DAD D1に対するリクエストが別のプロセス(プロセスP2)で取得された場合、プロセスP2のmod_plsqlは独自のデータベース接続をオープンし、リクエストを処理して、プールにそのデータベース接続を追加します。

  8. この時点から、DAD D1のプロセスP2に対する後続のすべてのリクエストは、mod_plsqlによってプールされたデータベース接続を使用できます。


    注意:

    複数の同時mod_plsqlリクエストがプロセスP2で処理される場合、必要に応じて同時mod_plsqlデータベース・リクエストに対応するために、追加のデータベース接続がオープンされます。

  9. ここで、リクエストR2がDAD D2に対して作成され、このリクエストがプロセスP1にルーティングされるとします。

  10. プロセスP1のmod_plsqlには、DAD D2用にプールされたデータベース接続がないため、新しいデータベース・セッションがDAD D2用に作成され、リクエストを処理した後にプールされます。この時点で、プロセスP1には、2つのデータベース接続がプールされています。1つはDAD D1用、もう1つはDAD D2用です。

    ステップ1から10に示されたこの例で、重要な詳細は次のとおりです。

    1. 各Oracle HTTP Serverプロセスは、静的ファイル・リクエスト、サーブレット・リクエストおよびmod_plsqlリクエストなど、すべてのタイプのリクエストを処理します。どのOracle HTTP Serverプロセスが次のリクエストを処理するかは制御できません。

    2. あるOracle HTTP Serverプロセスでは、別のプロセスで作成された接続プールの使用や共有はできません。

    3. 各Oracle HTTP Serverプロセスは、DADごとに最大でn個のmod_plsql接続をプールできます。nは、データベース・アクティビティの実行に必要な同時mod_plsqlリクエストの合計数です。

    4. ユーザー・セッションは、DADに対してプールされたデータベース接続内で切り替えられます。Oracle Application Server Single Sign-On(SSO)に基づくDADの場合、プロキシ認証を使用してユーザー・セッションが切り替えられます。SSO以外のユーザーの場合、DADにはないユーザー名およびパスワードによるHTTP Basic認証を使用して、ユーザーは同じ接続で再度認証されます。

    5. 複数のDADが同じデータベース・インスタンスを指すことがありますが、データベース接続は同じプロセス内であってもDAD間で共有されません。

    6. 未使用のDADには、データベース接続がありません。

最悪のシナリオでは、各DADにプールされるデータベース接続の合計数は、Oracle HTTP Server(httpd)プロセスの合計数と、単一プロセス内の同時mod_plsqlリクエストの最大数を掛けた数になります。Oracle HTTP Serverプロセスを大きい数に設定した場合、それに相当する数のデータベース・セッションを処理するように、バックエンド・データベースを設定する必要があります。この設定値には、バックエンド・データベースを使用するOracle HTTP Serverインスタンスの数を掛ける必要があります。mod_plsqlで必要なデータベース接続最大数を減らす場合は、Oracle HTTP Serverプロセス数の低減を考慮し、必要な同時実効性を達成するように各プロセス内でより多くのスレッドを実行する必要があります。単一プロセス内でより多くのプロセスを実行することの短所の1つとして、あるプロセスの失敗がプロセス内で実行されているすべてのスレッドに影響を与えることがあげられます。

たとえば、Oracle HTTP Serverインスタンスが3つあり、それぞれプロセスごとに1つのスレッドを持つ最大50のhttpdプロセスを作成するように設定されているとき、アクティブなDADが2つある場合、300(3*50*2)セッションを処理できるようにデータベースを設定する必要があります。この数には、他のWebアプリケーションが接続するのに必要なセッションは含まれていません。mod_plsqlで必要なデータベース接続最大数を減らす場合は、各インスタンスで50のhttpdプロセスを実行するのではなく、かわりに各プロセスで5つのスレッドを持つようにOracle HTTP Serverをチューニングして、HTTPDプロセス数を10に減らすことができます。このような設定で、データベース接続数の要求を減らすことができます。mod_plsqlの必要なデータベース接続数は、60(3*10*2)まで減らすことが可能です。実際には、各プロセスで実際に処理される同時mod_plsqlリクエスト数だけ減ります。

Windowsプラットフォームでは、Oracle HTTP Serverはシングル・プロセスとして実行されます。このようなシステムでは、mod_plsqlの接続プールはスレッド間で共有され、データベース接続の合計数は、各DADに対する同時リクエストの数になります。データベース接続がスレッド間で共有されるため、4.3.4項「2リスナー方針」はWindowsシステムには適用されません。

3.11.2 プールされたデータベース・セッションのクローズ

プールされたデータベース・セッションは、次の状況下でクローズされます。

  1. プールされた接続が、設定された数のリクエストを処理するために使用されている場合。

    デフォルトでは、mod_plsqlによってプールされた各接続は、最大1000リクエストを処理するために使用されます。その後、データベース接続は停止され、次のmod_plsqlリクエストで再確立されます。これは、PL/SQLベースのWebアプリケーションまたはOracleのクライアント/サーバー側でのリソース・リークがシステムに悪影響を及ぼさないようにするために行われます。デフォルト値の1000は、DAD設定パラメータのPlsqlMaxRequestsPerSessionをチューニングして変更します。

  2. プールされた接続が長期間アイドル状態である場合。

    デフォルトでは、mod_plsqlのクリーンアップ・スレッドにより、プールされた各接続は、アイドル時間が15分を経過するとクリーンアップされます。アイドル・セッションのタイムアウト値は、構成設定のPlsqlIdleSessionCleanupIntervalによって制御されます。サイトでmod_plsqlのコンテンツにアクセスする頻度が低いほど、アイドル・セッションのクリーンアップはより頻繁に発生するため、ユーザーはあまり使用されないデータベース接続を確立することになります。このような状況では、パフォーマンスを向上させるためにPlsqlIdleSessionTimeoutIntervalのデフォルト設定を大きくすることを検討します。プールされたデータベース接続を長時間オープンにしておくことは、より多くのセッションで使用できるようにするために、データベースに余分な負荷が発生することを意味します。

  3. UNIXシステムで、Oracle HTTP Serverプロセスが停止する場合。

    UNIXシステムでは、Oracle HTTP Server構成パラメータのMaxRequestsPerChildによってOracle HTTP Serverプロセスが停止するタイミングが制御されます。たとえば、このパラメータが5000に設定されている場合、各Oracle HTTP Serverプロセスは、正確に5000リクエストを処理した後、停止します。また、Oracle HTTP Serverプロセスは、構成パラメータのMinSpareServersMaxSpareServersおよびMaxClientsに基づいて、Oracle HTTP Serverのメンテナンスの一環として起動および停止することがあります。

    Oracle HTTP Serverが正しく設定されていないと、Oracle HTTP Serverプロセスが頻繁に起動および停止するようになり、その結果、無駄なmod_plsqlの接続プーリングが発生します。最高のパフォーマンスにするには、各Oracle HTTP Serverプロセスが一定時間アクティブの状態を維持し、プロセスが停止しないように、Oracle HTTP Serverを設定します。


    関連項目:

    『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。

  4. mod_plsqlが接続プールで停止中の接続を検出した場合。

    詳細は、3.11.3項「接続プールでの停止中のデータベース接続の検出」を参照してください。

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がまだ最初の停止中の接続を検出していない場合、その時点では複数の障害が発生する可能性があります。


関連項目:

mod_plsqlリクエストがサーバーに対して作成されていない場合でも、mod_plsqlが停止中のデータベース接続をクローズする他の状況の詳細は、3.11.2項「プールされたデータベース・セッションのクローズ」を参照してください。

mod_plsqlでは、停止中のデータベース接続の検出機能をチューニングするための構成オプションを2つ提供しています。

3.11.3.1 停止中のデータベース接続を検出するためのオプションの指定

mod_plsqlは、データベース・ノードの停止が原因と考えられる障害を検出すると接続を修正します。これは、PlsqlConnectionValidationパラメータによって制御されます。PlsqlConnectionValidationパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。

3.11.3.2 タイムアウト期間の指定

PlsqlConnectionValidationパラメータがAutomaticまたはAlwaysValidateに設定されていると、mod_plsqlはプールされているデータベース接続をテストしようとします。

mod_plsqlが接続プールの不完全なデータベース接続をテストするタイムアウト期間を指定できます。これは、PlsqlConnectionTimeoutパラメータで制御されます。このパラメータには、テスト・リクエストが完了するまでmod_plsqlが待機する最大時間を指定します。この時間を超えると、接続が使用不可とみなされます。

PlsqlConnectionTimeoutパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「mod_plsql」を参照してください。

3.12 mod_plsqlでの制限事項

mod_plsqlには、次の制限があります。