pureQuery データを保管するためのオプション

pureQuery® クライアント最適化対応のアプリケーションを実行するときには、pureQuery Runtime がランタイム構成情報や pureQueryXML 情報を取得する場所を指定できます。 SQL データをキャプチャーする場合は、データを保管する場所を指定できます。
通常、pureQuery クライアント最適化を有効にする処理中や実行時に使用される以下のファイルを作成します。
  • pureQuery Runtime 構成プロパティー・ファイル
  • 実行時に使用する SQL データを含む pureQueryXML ファイル
  • プロパティー・ファイルの構成およびプロパティー・ファイルのバインド
  • キャプチャーされた SQL データを含む pureQueryXML ファイル
pureQuery のプロパティーやデータを保管する場所を決める必要があります。 pureQuery Runtime のデフォルトの場所を使用することも、場所を指定することもできます。
ローカル・ファイル・システム (デフォルト動作)
デフォルトでは、pureQuery Runtime はローカル・ファイル・システム上でプロパティーやデータを探します。 このモデルの場合、pureQuery ランタイム・プロパティーの pureQueryXml および outputPureQueryXml は、pureQuery データを含むファイルを指定します。 これら 2 つのプロパティーは、pdq.properties および pdq.appwide.properties というファイルなど、さまざまな場所で指定されることがあります。
ファイル・システムまたはデータベース内のリポジトリーの指定
pureQuery のデータおよびランタイム・プロパティーは、データベース内のリポジトリー、ファイル・システム、または両方に存在させるように指定することもできます。 pureQuery ランタイム・プロパティーの 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 ランタイム・プロパティー repositoryRequired を値 atStartUp で指定する必要があります。

同様に、アプリケーションの実行中に出力データのキャプチャーが重要な場合は、repositoryRequired プロパティーを値 forOutput で指定することにより、アプリケーション開始時に出力データベースの可用性を pureQuery Runtime に検証させることができます。 ほとんどの場合、この設定は必要ありません。 アプリケーションの実行中に出力データベースが使用可能になった場合は、pureQuery は変更を検出し、出力の書き込みを開始します。

入力および出力の両方の pureQueryXml データベースが使用できることを確認する必要がある場合は、repositoryRequired プロパティーを値 atStartupAndForOutput で指定できます。 この設定も初期構成時に便利なオプションであり、すべてが正しく構成されていることを確認し、正しく構成されなかったものが判明するまで、長時間アプリケーションの実行を回避します。

pureQuery 情報の自動リフレッシュ
デフォルトでは、pureQuery Runtime は、ランタイム・グループ・バージョンがアクティブ化された後に、ランタイム・グループ・バージョン用の pureQuery 情報に対する更新を検査します。 ランタイム・グループ・バージョンがアクティブ化されており、ランタイム・グループ・バージョン用の pureQuery データが更新されている場合、pureQuery Runtime はデータをリフレッシュします。

メンテナンス更新を頻繁に受信するアプリケーションや、以前にキャプチャーされていない SQL を生成し続けるフレームワークは、自動リフレッシュに適した候補です。 指定される間隔は、反映されたアップデートを確認する場合の緊急性によって異なります。 多くのアプリケーションでは、1 日に 1 回リフレッシュすれば十分です。

キャプチャーや、動的から静的への最初の切り替え時など、初期アプリケーション・セットアップ中に、頻繁な間隔 (2 分など) ですぐに変更を更新することもあります。

場合によっては、自動リフレッシュ機能を使用不可にしたいこともあります。 デプロイメント後のアプリケーションにおいて、メンテナンス更新がほとんどあるいはまったく起こらない場合、すべての SQL のキャプチャーとバインドが事実上済んでいれば、キャプチャー・モードを継続的に実行したり、自動リフレッシュを使用可能にする必要はほとんどありません。

pureQuery Runtime プロパティー runtimeGroupActivationCheckInterval および propertiesRefreshInterval は、ランタイム・グループ・バージョンの pureQuery 情報の自動リフレッシュを制御します。
  • runtimeGroupActivationCheckInterval プロパティーは、アクティブ化されたランタイム・グループのバージョンを pureQuery Runtime がいつ検査するかを制御します。 JVM で実行されるすべての pureQuery Runtime インスタンスに適用されるよう、このプロパティーを設定する必要があります。
  • propertiesRefreshInterval プロパティーを使用すると、ランタイム・グループ・バージョンの pureQuery 情報の更新を検査するための特定の間隔を指定できます。 また、ランタイム・グループ・バージョンがアクティブ化されたときに行われる検査も含めて、ランタイム・グループ・バージョンの pureQuery 情報の更新に関する検査をすべて無効にするよう、プロパティーを設定することもできます。

これらのプロパティーについては、runtimeGroupActivationCheckInterval プロパティーおよびpropertiesRefreshInterval プロパティーを参照してください。


フィードバック