動的照会の使用が便利なときは、アプリケーション・パフォーマンスに影響を与える場合があります。
一般的なパフォーマンス考慮事項
動的照会で以下のエレメントを使用すると、アプリケーションのパフォーマンスが若干低下する可能性があります。
理由: 一般に、照会操作と照会の述部はデータベースがそれらを実行できるように、SQL に翻訳されます。 しかし、照会がデータ型コンバーター (例えば、EJB の RDB マッピング用) や Java メソッドを含んでいる場合は、照会の該当する述部や操作は、 アプリケーション・サーバーのメモリーで実行されなければなりません。
理由: これらのエレメントを取り込んだ照会は、アプリケーション・サーバーのメモリーで EJB の完全な活動化を起動します。 (照会から CMP フィールドのリストの戻りでは、EJB は活動化されません。)
アプリケーション・パフォーマンスにアクセスする場合、動的照会がパーシスタンス・マネージャーとの接続を共有していることも知っている必要があります。 その結果、ファインダー・メソッド、CMR ナビゲーション、動的照会を混合して含むアプリケーションは、 これらのタスクを実行するためにパーシスタンス・マネージャーと動的照会サービスとの間の単一の共有接続に依存します。
戻りコレクションのサイズの制限
しかし、ローカル・インターフェースの照会におけるある種の操作の使用は、demand-driven の動作をオーバーライドします。 このような場合、照会の結果はリモート・インターフェースの照会での結果コレクションとちょうど同じように、メモリーで完全に具体化されます。 次に例を挙げます。
select e.myBusinessMethod( ) from EmpBean e where e.salary < 50000 order by 1 desc
この照会には、最終結果コレクションを生成するための EJB メソッドの実行が必要です。 その結果、データベースからの完全なデータ・セットは 1 つのコレクションでアプリケーション・サーバーのメモリーに戻される必要があります。 そのメモリーでデータ・セット全体に対して EJB メソッドが実行できます。 このため、EJB メソッドを呼び出すローカル・インターフェースの照会操作は一般に demand-driven ではありません。 そのような照会の戻り値コレクションのサイズは制御できません。
これらの操作は demand-driven である ため、他のすべてのローカル・インターフェースの照会で戻り値コレクションのサイズを制御できます。 データ・ストアから希望する数の戻り値を取り出した後、QueryLocalIterator オブジェクトで close() メソッドの呼び出しを使用し、 照会ループをクローズすることができます。 そうしない場合は、完全な結果セットがメモリーに累積されるか、トランザクションが終了するまで、EJB 照会の実行に使用する SQL カーソルは閉じられません。