データ・バインドされたBC4J JSPページは、アプリケーション・モジュールのインスタンスを介してビジネス・コンポーネントにアクセスします。アプリケーション・モジュール・インスタンスについて、JSPセッション中にどのように割り当てられるか、状態が保存されるかどうか、データベースからのフェイルオーバー・サポートがあるかどうかを決定できます。Business Components for Java(BC4J)フレームワークでのアプリケーション・モジュール・プールの実装は、次の3つのモードをサポートします。
JSPページ用に選択するモードは、生成するWebアプリケーションのタイプに依存します。次のセクションではそのオプションと、ビジネス・コンポーネントでキャッシュされるデータにアクセスするWebアプリケーションで、それらのオプションがどのような役割を果たしているかについて説明します。
データ・バインドされたBC4J JSPアプリケーションでのアプリケーション・モジュール状態管理について
ページの処理中に、ページに対するHTTPリクエストは、各アプリケーション・モジュールの限定されたインスタンス・プールを共有します。ステートレスJSPアプリケーションでは、アプリケーション・モジュールの特定のインスタンスへのアクセスは、ページ・リクエストの継続中のみ維持されます。ステートレス・オプションが指定されたApplicationModuleデータ・タグが処理された後には、アプリケーション・モジュール・インスタンスは解放され、そのアプリケーション・モジュールのインスタンス・プールに戻される必要があります。
個々のJSPページまたはJSPアプリケーション全体にデフォルトのステートレス・オプションを選択した場合、データ・タグは、特定のHTTPセッションで新しいページが起動されるたびに、必ず同じアプリケーション・モジュール・インスタンスにアクセスするわけではありません。このため、ビュー・オブジェクトの(1回起動されたものが次に起動されるまで同じものが保持されている)行セットは使用できません。この動作は、JSPページがそれぞれ独立して動作しており、状態を維持する必要のある単一のタスクを表していない場合に望ましい動作です。JSPページの大多数がアプリケーション・モジュール・インスタンスをステートレスに解放できるようにすると、アプリケーション・モジュールの状態管理にともなうオーバーヘッドが削減され、JSPアプリケーションが可能なかぎり高レベルのパフォーマンスで稼働することが保証されます。
ApplicationModuleデータ・タグに対してステートフル・オプションを指定した場合も、JSPアプリケーションのデータ・タグは、そのアプリケーションが起動するたびに同じアプリケーション・モジュール・インスタンスにアクセスするとはかぎりません。ただし、ステートレスJSPページとは異なり、Business Components for Javaは、アプリケーション・モジュールの解放時にアプリケーション・モジュールの状態を(passivationstoreパラメータの値に応じて)データベース、ファイルまたはメモリーに保存するため、ビュー・オブジェクトの行セットでは1回起動されたものが次に起動されるまで同じものが保持されます。ステートフル・モードは、次の場合に適しています。
1つのタスクを完了するためにユーザーが対話する一連のJSPページ間で情報を保持する場合
ユーザーにより送られた変更をあるページから次のページに保持する場合
ステートフル・モードでは、Business Components for Javaはデータベースのフェイルオーバーをサポートし、アプリケーション・モジュール・プールが効率的に使用されるようにします。アプリケーション・モジュール・プール・マネージャは、現在位置や、あるJSPページから次のJSPページに渡される必要のあるすべての動的アプリケーション情報などのアプリケーション状態を管理します。ステートフル・モードは、ユーザーがデータの変更を行うようなページを使用するかにかかわらず役立ちます。Business Components for Javaを利用して前のHTTPリクエストへの問合せの復元を管理するほうが、APIを使用してこれらのタスクをプログラムで実行するよりも簡単で効率的です。
重要: ユーザーがデータをステートフル・モードまたはリザーブ・モードで変更することを許可する場合は、次の「データ・バインドされたBC4J JSPアプリケーションのデータベース・トランザクションについて」に示すようにCommitデータ・タグを使用してデータベースに変更を送る必要があります。
ApplicationModuleデータ・タグに対してリザーブ・オプションを指定した場合は、データ・タグがアプリケーション・モジュールに一度接続されると、その後同じHTTPセッション中に任意のデータ・タグからそのアプリケーション・モジュールに接続した場合も、アプリケーション・モジュールの同じインスタンスが使用されます。これは、後続の接続が別のJSPページからの場合も、同じJSPページの新規の起動の場合も同じです。このモードは、ステートフル・アプリケーションと似ていますが、フェイルオーバーはサポートせず、アプリケーション・モジュールの再利用もできません。リザーブ・モードは、イントラネット・タイプの環境で使用すると便利です。
Webアプリケーションのユーザーがデータ・バインドされたBC4J JSPページを介してデータを変更し、データを処理するためにJSPページで「送る」をクリックすると、Webアプリケーション・フレームワーク(基本的にBusiness Components for Java)は、解放時のアプリケーション・モジュールの状態に応じて異なる方法でデータベース・トランザクションを処理します。
解放モード | アプリケーション・モジュールの動作 | データベース・トランザクションおよびユーザーの操作 | アプリケーション・モジュール・ロックの動作 |
---|---|---|---|
ステートレス |
ページ処理リクエスト間でアプリケーション・モジュール・インスタンスの状態を保持しません。インスタンスは、JSPページの終了後すぐに解放されます。 注意: JSPアプリケーションに多数のユーザーが同時にアクセスすることが想定される場合に、このオプションを選択します。ステートレス・オプションでは、多くのユーザーがJSPアプリケーションに同時にアクセスできますが、ユーザーは、JSPページを起動(または再起動)するたびに新しいアプリケーション・モジュール・インスタンスに再接続されます。 |
ステートレス・モードでは、リクエスト間でアプリケーション・モジュールの状態が維持されないため、Webアプリケーション・フレームワークは変更を自動的にポストおよびコミットします。ユーザーは、ステートレス・モードでコミットを開始する必要はありません。JSPページの「コミット」および「ロールバック」は使用不可になります。 |
ステートレス・モードでは、BC4Jプロパティ |
ステートフル |
ページ処理リクエスト間でアプリケーション・モジュール・インスタンスの状態をデータベースに保持します。これにより、アプリケーションは、単一のアプリケーション・モジュール・インスタンスを長期間使用せずにユーザーのデータを維持できます。 注意: ステートフル・モードは、HTTPセッションに対してフェイルオーバー・サポートを提供します。アプリケーション・モジュールで標準JDBC接続を使用する場合に適しています。 |
Webアプリケーション・フレームワークは、ページ・リクエストの終了時に、データ変更を含むアプリケーション・モジュールの状態をデータベースに単純に保存します。このモードでは、ユーザーは、プロセスのJSPページで「コミット」をクリックしてコミットを開始します。ユーザーが「コミット」をクリックすると、フレームワークはデータベースに対するポストおよびコミットを(まとめて1つのステップとして)すぐに開始します。オプションとして、ユーザーは「ロールバック」をクリックし、ポストを開始せずに変更がデータベースに入力されることを防ぐことができます。アプリケーション・モジュールの状態は保存されるため、ユーザーは、HTTPセッション中に任意の時点でコミットまたはロールバックを開始できます。 |
ステートフル・モードでは、BC4Jプロパティ |
リザーブ |
ブラウザ・セッションの間アプリケーション・モジュール・インスタンスを割り当てます。インスタンスは、セッションの終了時にのみ解放されます。このモードは、主に特定のアプリケーション・モジュール定義との互換性を保つためのものです。このモードではフェイルオーバーはサポートされません。 注意: リザーブ・モードは、主にアプリケーション・モジュールで標準以外のJDBC接続定義が必要な場合に便利です。このモードではフェイルオーバーはサポートされません。 |
Webアプリケーション・フレームワークは、変更をデータベースに自動的にポストします(また、影響を受ける表に対してDMLで指定されたデータベース・トリガーを開始します)。このモードでは、ユーザーは、プロセスのJSPページで「コミット」または「ロールバック」をクリックするといった操作でトランザクションの終了を通知することが必要になります。アプリケーション・モジュール自体はHTTPセッション中は解放されないため、ユーザーは任意の時点でコミットまたはロールバックを開始できます。 |
リザーブ・モードでは、即時ロックを信頼して使用でき、プロパティ |
Oracle9i JDeveloperのアプリケーション・モジュール・プールの命名
JDeveloper 3.2では、JSPページをデータ・タグで生成すると、データ・バインドされたJSPファイルにより次のようにアプリケーション・モジュールが定義されます。
<jbo:ApplicationModule configname="bc4j1.Bc4j1Module.Bc4j1Module9iAS"
id="Bc4j1Module" />
JDeveloper 3.2では、アプリケーション・モジュール・プールの名前にid
値が使用されていました。Oracle9i JDeveloperからは、プールの名前にconfig
値が使用されます。JDeveloper 3.2 JSPアプリケーションからOracle9i JDeveloperへ移行する場合は、Javaのプール名参照を編集する必要があります。たとえば、次のJavaコードは、Oracle9i JDeveloperで、前述のデータ・タグで示したアプリケーション・モジュールの定義はNullPointerExceptionを返します。
<%
oracle.jbo.common.ampool.PoolMgr mgr = oracle.jbo.common.ampool.PoolMgr.getInstance();
oracle.jbo.common.ampool.ApplicationPool pool = mgr.getPool("Bc4j1Module");
pool.commitAndSyncCache(ds1.getRowSet().getApplicationModule());
%>
configname
値をかわりに使用するため、getPool()
メソッドを編集します。
oracle.jbo.common.ampool.ApplicationPool pool = mgr.getPool("bc4j1.Bc4j1Module.Bc4j1Module9iAS");
個々のWebアプリケーションでのアプリケーション・モジュール使用の同期
単一サーバー上で同じビジネス・コンポーネントにアクセスする複数のWebアプリケーションをデプロイする場合、そのビジネス・コンポーネントのクライアントが同じアプリケーション・モジュールのインスタンスを共有できないようにします。プロパティjbo.server.in_oc4j
をtrue
に設定し、OC4Jインスタンス内でBC4Jが稼働していることを宣言すると、アプリケーション・プール・マネージャにより、アプリケーション・プール・インスタンスがアプリケーション間で共有されないようにできます。このプロパティを指定するには、OC4Jコマンドラインで次のように入力します。
java -D jbo.server.in_oc4j=true -jar oc4j.jar
マルチフレーム型Webアプリケーションでのアプリケーション・モジュール使用の同期
Webアプリケーションのユーザーが、1回のHTTPセッション中に異なるJSPページを介して同じアプリケーション・モジュール・インスタンスにアクセスする場合、ランタイム・エラーが発生する場合があります。これは、そのユーザーが異なるフレームでJSPページを実行したことが原因です。各フレームには、使用のために同じアプリケーション・モジュールが渡されるためです。したがって、あるビュー・オブジェクトがいずれかのJSPページで終了すると、もう一方のビュー・オブジェクトの結果セットも終了し、ランタイム例外が生成されます。
この問題が発生しないようにするには、次の2つの方法があります。
方法1:
方法2:
RowSet rs = vo.getRowSet();
または
Row[] rows = vo.getAllRowsInRange();
JSPページおよびビジネス・コンポーネントについて
アプリケーション・モジュールおよびトランザクションについて
BC4Jデータ・タグについて
JSPプロジェクトのBC4J構成プロパティについて
bc4j.xcfgファイルでのBC4J JSPランタイム・プロパティの定義
単純なBC4J JSPページへのJSPデータ・バインドの追加
データ・タグを使用したアプリケーション・モジュールの状態管理