pureQuery クライアント最適化対応のアプリケーションを実行する場合は、
pureQuery Runtime がランタイム構成情報および pureQueryXML 情報を取得する場所を指定できます。
SQL データをキャプチャーする場合は、データを保管する場所を指定できます。
通常、pureQuery クライアント最適化を使用可能にする処理中および実行時に使用される以下のファイルを作成します。
- pureQuery Runtime 構成プロパティー・ファイル
- 実行時に使用する SQL データを含む pureQueryXML ファイル
- プロパティー・ファイルの構成およびプロパティー・ファイルのバインド
- キャプチャーされた SQL データを含む pureQueryXML ファイル
pureQuery のプロパティーおよびデータを保管する場所を決める必要があります。
pureQuery Runtime のデフォルトの場所を使用することも、場所を指定することもできます。
- ローカル・ファイル・システム (デフォルト動作)
- デフォルトで、pureQuery Runtime はローカル・ファイル・システム上でプロパティーおよびデータを探します。
このモデルの場合、pureQuery Runtime プロパティーの pureQueryXml および outputPureQueryXml は、pureQuery データを含むファイルを指定します。
これら 2 つのプロパティーは、pdq.properties および pdq.appwide.properties というファイルなど、さまざまな場所で指定されることがあります。
- ファイル・システムまたはデータベース内のリポジトリーの指定
- pureQuery のデータおよびランタイム・プロパティーは、データベース内のリポジトリー、ファイル・システム、または両方に存在させるように指定することもできます。
pureQuery Runtime プロパティーの finalRepositoryProperties および outputXmlRepository を使用して、場所を指定します。
pureQuery クライアント最適化に対応しているアプリケーションを使用して、pureQuery データをリポジトリーに保管する場合は、pureQuery ユーティリティー ManageRepository を使用して、pureQuery データにアクセスし、リポジトリーに保管します。
ManageRepository ユーティリティーを使用して、リポジトリーの作成、管理、および保守を行うことができます。
pureQuery のデータおよびプロパティーをリポジトリーに保管することによる利点はありますが、リポジトリーを作成および保守する際に適切に計画する必要があります。
リポジトリーを使用する利点
pureQuery データ用の中央ストアとして、データベース内のリポジトリーを使用する利点は、以下のとおりです。
- 実行中のアプリケーションを中断せずに、pureQuery データに対するアクセスやアップデートが行えます。
- 集中的に管理されるリポジトリーにより、pureQuery プロパティーおよび XML ファイルの単一のコピーを、複数のアプリケーション・サーバー上にデプロイされたアプリケーションで使用することができます。
- pureQuery プロパティーおよび XML ファイルに対するアップデートを定期的にチェックし、新しいデータの使用を自動的に開始するように、実行中のアプリケーションを構成できます。
- pureQuery データに対するアクセスおよびアップデートの権限をデータベースによって強制できます。
- 管理者はより簡単に、pureQueryXML ファイルを検査して、アプリケーションの SQL を調べ、問題のある SQL ステートメントがある場合には、ソース・コードのロケーション情報を確認できます。
リポジトリー構成の考慮事項
データベースを使用して pureQuery の成果物を保管する場合は、構成に関してかなり柔軟性があります。
主な判断ポイントは、以下のとおりです。
- pureQuery データを含む 1 つまたは複数のデータベースがどこに存在するか。
- アプリケーションが初期化中にリポジトリーにアクセスできない場合、アプリケーションがどのような反応を示すべきか。
- アプリケーションで自動リフレッシュ機能を使用すべきか。その場合、リポジトリー DBMS をポーリングしてアップデートする推奨間隔はどのくらいか。
- リポジトリー・データベースの場所の決定
- 2 つのタイプのデータとして、以下の入力データと出力データがあります。
- pureQuery Runtime の実行および構成データ (入力)
- pureQuery のキャプチャーされた SQL データ (出力)
入力データおよび出力データに異なる場所を使用するようにアプリケーション実行環境を構成できます。
各タイプのデータの位置を以下のいずれかによって指定できます。
- アプリケーションがトランザクション処理を実行する、同じデータベース (トランザクション・データベース)
- アプリケーション・サーバーと同じ場所で実行するデータベース
- アプリケーションまたはトランザクション・データベース・サーバーから独立しているリモート・データベース
デフォルトの推奨情報: 入力および出力の両方に対して、トランザクション・データベース内に単一のリポジトリーを作成する。
以下の 2 つの利点があります。
- 簡易さ
- このアプローチは、独立したデータベースにデータを作成して保守する必要性がなくなるため、簡易化できます。
- 可用性
- 初期化中に pureQuery データベース・リポジトリーを使用できない場合は失敗するようにアプリケーションを構成できます。
このような場合、トランザクション・データベースを使用すると、通常トランザクション・データベースは優れた可用性などのサービス品質の特性を備えているため、アプリケーションの可用性が向上する傾向があります。
同じような特性を持つ独立したサーバーを使用している場合は、障害が起こり得るポイントが増加します。
データベースの場所に関するその他の考慮事項:
- pureQuery の自動リフレッシュまたは出力キャプチャー・レコードの書き込みによって、トランザクション・データベース内またはネットワーク上で増加するアクティビティーについて懸念がある場合は、リポジトリー・データベースをアプリケーション・サーバーまたは独立したサーバー上に配置することを検討します。
- トランザクション・データベースで許可するデータのタイプについて、ご使用のサイトで標準を設定していることもあります。
これらの要件が、データベース用に独立したサーバーを選択する要因になる場合もあります。
- 検討すべき妥協案の 1 つは、入力データ・リポジトリーをトランザクション・データベース上に配置し、出力キャプチャー・レコードを保管するためのリポジトリーを独立したサーバー上に作成することです。
- 入力データをデータベース・リポジトリーに、出力データをローカルまたはリモートのファイル・システムに保管する、組み合わせによる構成も許容されます。
- リポジトリーが使用できないときの動作
- アプリケーションの開始時に pureQuery データが使用できない場合、アプリケーションをどのように動作させたいか、前もって検討しておくことが重要です。
pureQuery Runtime の時間のプロパティー repositoryRequired は、動作を制御します。
デフォルト設定の no を使用すると、pureQuery Runtime は、すべての pureQuery クライアント最適化プロパティーのデフォルトの動作に戻ります。
これは、動的 SQL を使用してアプリケーションが実行されることを意味します。
アプリケーション開始時のアプリケーションの失敗よりも、このフォールバックが優先される場合は、デフォルトの動作を続けます。
ただし、SQL ステートメントを静的に実行したときなど、場合によっては、デフォルトの動作でのアプリケーションの実行に問題があったり、実行できなかったりする可能性があります。
例えば、SQL ステートメントを準備し、動的に実行する権限は、すべてのアプリケーション・ユーザーに与えられていないことがあります。
そのような場合には、pureQuery Runtime プロパティー repositoryRequired を値 atStartUp で指定する必要があります。
同様に、アプリケーションの実行中に出力データのキャプチャーが重要な場合は、repositoryRequired プロパティーを値 forOutput で指定することにより、アプリケーション開始時に出力データベースの可用性を、pureQuery Runtime に検証させることができます。
ほとんどの場合、この設定は必要ありません。
アプリケーションの実行中に出力データベースが使用可能になった場合は、pureQuery は変更を検出し、出力の書き込みを開始します。
入力および出力の両方の pureQueryXml データベースが使用できることを確認する必要がある場合は、repositoryRequired プロパティーを値 atStartupAndForOutput で指定できます。
この設定も初期構成時に便利なオプションであり、すべてが正しく構成されていることを確認し、正しく構成されなかったものが判明するまで、長時間アプリケーションの実行を回避します。
- 自動リフレッシュ間隔
- propertiesRefreshInterval プロパティーを使用することにより、長期間実行するアプリケーションおよびキャッシュされた接続の pureQuery Runtime プロパティーおよび pureQueryXML を自動的にリフレッシュする pureQuery 機能を使用可能にできます。
この機能はデフォルトでオフになっていますが、リフレッシュの試行間隔を分単位で示す正の整数値を指定することにより、定期的なポーリングおよびリフレッシュを使用可能にできます。
メンテナンス更新を頻繁に受信するアプリケーション、および以前にキャプチャーされていない SQL を生成し続けるフレームワークは、リフレッシュに適した候補です。
指定される間隔は、反映されたアップデートを確認する場合の緊急性によって異なります。
多くのアプリケーションでは、1 日に 1 回リフレッシュすれば (propertiesRefreshInterval を 1440 の値で指定) 十分です。
キャプチャーや、動的から静的への最初の切り替え時など、初期アプリケーション・セットアップ中にさらに頻繁な間隔 (10 分など) ですぐに変更をアップデートすることもあります。
この機能は使用不可のままにしておくことがほとんどです。
デプロイメント後のアプリケーションにおいて、メンテナンス更新がほとんどあるいはまったく起こらない場合、すべての SQL のキャプチャーとバインドが事実上済んでいれば、キャプチャー・モードを継続的に実行したり、自動リフレッシュを使用可能にする必要はほとんどありません。
また、pureQuery
Runtime で新しいランタイム・プロパティーまたは pureQueryXML を認識させる必要があるときはいつても、アプリケーションおよびアプリケーション・サーバーの再始動が簡単にできる場合は、自動リフレッシュ機能を使用する必要はありません。
自動リフレッシュを使用可能にしていて、後からアプリケーションの実行中にリフレッシュ間隔を変更する場合は、
データベース・リポジトリーのプロパティーの値を変えることにより、変更することができます。
pureQuery は次の間隔で変更を検出し、以降は新しい値に切り替えます。