WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

動的 EJB 照会サービスとデプロイメント EJB 照会サービスの比較

動的照会サービスを使用すると、エンティティー Bean に対する照会をデプロイメント時に定義するのではなく、それらの照会を実行時に動的に構成して、構築したり実行したりすることができます。 動的照会を使用することによって、実行時に照会を定義するといった柔軟性を持たせたり、EJB-QL 言語 (QL) の力を使用したりすることができます。 EJB-QL 照会のすべての機能をサポートするのとは別に、動的照会は、標準的な静的照会では使用できない機能を追加します。 例を 2 つ挙げるとすれば、Bean そのものから直接複数のデータ・フィ ールドを選択する機能 (現在は静的照会でのみ許可されています) と、ビジネ ス・メソッドを照会で直接実行することです。

動的照会では、より効率的で、リソースにあまり依存しないアプリケーションを、効果的に作成することができます。 例えば、1 つの照会の結果から 2 つのデータ・フィールドが必要な場合などです。 標準的な EJB-QL 照会はデータ・フィールドを 1 つしか選択できないので、EJB オブジェクト全体を選択して、戻された結果からデータ・アクセス方式によって必要なデータを抽出する必要があります。 その過程でおそらく、コンテナー管理関連 (CMR) の範囲を全検索することになるでしょう。 ただし、動的照会を使用する場合、CMR の全検索または accessor メソッドを追加しなくても、照会から直接両方のデータを取得することができます。 この原則は、動的照会がパフォーマンス向上に使用できるかどうかを評価する際には重要です。 データの検索に必要なビジネス・ロジック (例えば CMR の全探索または accessor メソッド) の量だけでなく、 検索しなければならないデータの量も検討する必要があります。

リテラル値ではなく照会内のパラメーターを使用することも、また別のパフォーマンスに関する考慮事項です。 ほとんどの環境では、条件付きの値を照会のパラメーターとして定義してから、 それらのパラメーターを適切なメカニズムを経由して渡す方が適しています。 この方法を使用すると、キャッシュされた照会計画をマッチングする機会が より多くなり、計画を最初から構文解析して構築する必要がなくなります。例えば 、"SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE foo" は、 値 foo を executeQuery メソッドのパラメーターとして渡し 、"SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE ?1" と表す方が適切です。 その結果、ストリング・リテラル条件が異なる以外は同じ動的照会構造をこ れ以後に実行すると、それらはすべて計画キャッシュ・ヒットとして登録さ れます (「監視」パフォーマンスによりよい影響を与えます)。

動的照会は、それと同等の静的照会の直接の代替機能として使用される 場合、静的変動よりも約 25% 緩慢です。 この速度低下は、照会計画を構文解析して構築し、さらには実行する必要があるためです。 静的変動では、これらのコストはデプロイ時に支払われます。 それでも、動的照会を使用することによって得られる追加機能 (たとえ CMR 経由であっても、1 つの照会で複数のデータ・フィールドを選択できる機能) によって、動的照会をパフォーマンス向上のために使用する機会が与えられます。




関連タスク
EJB 照会の使用
動的照会サービスの使用
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rprf_dynqtune.html