動的照会のパフォーマンスに関する考慮事項
動的照会の使用が便利なときは、 アプリケーション・パフォーマンスに影響を与える場合があります。
一般的なパフォーマンスの考慮事項
動的照会で以下のエレメントを使用すると、アプリケーションのパフォーマンスが若干低下する可能性があります。
- データ型コンバーターと Java™ メソッド
理由: 一般に、照会操作と照会の述部はデータベースがそれらを実行できるように、SQL に翻訳されます。 しかし、照会にデータ型コンバーター (例えば、 EJB から RDB へのマッピング用) や Java メソッドが含まれている場合は、照会の関連述部とオペレーションは、 アプリケーション・サーバーのメモリー内で実行されなければなりません。
- EJB 参照の戻り値を呼び出す EJB メソッドおよび基準
理由: これらのエレメントを取り込んだ照会は、アプリケーション・サーバーのメモリーで EJB の完全な活動化を起動します。 (照会から CMP フィールドのリストの戻りでは、EJB は活動化されません。)
アプリケーション・パフォーマンスにアクセスする場合、動的照会がパーシスタンス・マネージャーとの接続を共有していることも知っている必要があります。 その結果、ファインダー・メソッド、CMR ナビゲーション、動的照会を混合して含むアプリケーションは、 これらのタスクを実行するためにパーシスタンス・マネージャーと動的照会サービスとの間の単一の共有接続に依存します。
戻りコレクション・サイズの制限
- リモート・インターフェースの照会: リモート・インターフェースの QueryIterator クラスにより、すべての照会結果が 1 つのメソッドの呼び出しによってアプリケーション・サーバーのメモリーで具体化されます。EJB 照会の実行に使用する SQL カーソルは、その呼び出しの終了時にクローズされます。
この条件はデータベース・サーバー内にボトルネックを生じさせる可能性が高いため、
大量の戻りコレクションの可能性がある場合は、そのサイズを制限することが必要です。
- ローカル・インターフェースの照会: ほとんどの場合、QueryLocalIterator オブジェクトは SQL カーソルのラッパーとして動作します。これは demand-driven、すなわちデータは増分的に戻されます。データベースからレコードを検索するごとに、next() メソッドがイテレーターで呼び出される必要があります。
しかし、ローカル・インターフェースの照会におけるある種の操作の使用は、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 カーソルは閉じられません。