Hinweise zur Leistung bei dynamischen Abfragen
Die Verwendung einer dynamischen Abfrage kann einerseits praktisch sein, andererseits kann sie in manchen Fällen die Anwendungsleistung beeinträchtigen.
Allgemeine Hinweise zur Leistung
Wenn Sie in einer dynamischen Abfrage die folgenden Elemente verwenden, kann die Anwendungsleistung etwas zurückgehen:
- Datentypumsetzer und Java-Methoden
Grund: Im Allgemeinen werden Abfrageoperationen und -prädikate in SQL umgesetzt, damit sie vom Datenbankserver ausgeführt werden können. Falls Ihre Abfrage Datentypumsetzer (z. B. für die EJB-RDB-Zuordnung) oder Java-Methoden enthält, müssen die zugehörigen Prädikate und Operationen der Abfrage im Speicher des Anwendungsservers ausgeführt werden.
- EJB-Methoden und Bedingungen, die die Rückgabe von EJB-Referenzen erfordern
Grund: Abfragen, die diese Elemente enthalten, führen zu einer vollständigen Aktivierung von EJBs im Speicher des Anwendungsservers. (Die Rückgabe einer Liste von CMP-Feldern von einer Abfrage hat keine Aktivierung einer EJB zur Folge.)
Wenn Sie über die Anwendungsleistung nachdenken, sollten Sie auch beachten, dass dynamische Abfragen Verbindungen gemeinsam mit dem Persistence Manager verwenden. Eine Anwendung mit einer Mischung aus Finder-Methoden, CMR-Navigation und dynamischen Abfragen ist demzufolge auf eine gemeinsam mit dem Persistenzmanager verwendete Verbindung angewiesen und muss sich darauf verlassen, dass der dynamische Abfrageservice diese Tasks ausführt.
Größe der zurückgegebenen Objektgruppen begrenzen
- Remote-Interface-Abfragen: Die Klasse "QueryIterator" der fernen Schnittstelle verlangt, dass
alle Abfrageergebnisse im Verlaufe eines Methodenaufrufs im Speicher des Anwendungsservers abgelegt werden können. Die für die Ausführung einer
EJB-Abfrage verwendeten SQL-Cursor werden bei Beendigung dieses Aufrufs geschlossen. Diese Voraussetzung birgt ein hohes Risiko,
innerhalb des Datenbankservers Engpässe zu erzeugen. Daher müssen Sie die Größe aller potenziell umfangreichen Ergebnisobjektgruppen
begrenzen.
- Abfragen der lokalen Schnittstelle: In den meisten Fällen verhält sich das Objekt "QueryLocalIterator"
wie ein Wrapper um einen SQL-Cursor. Es ist bedarfsabhängig und bewirkt, dass Daten
schrittweise zurückgegeben werden. Für jeden Abruf eines Datensatzes aus der Datenbank muss die Methode
next() für den Iterator aufgerufen werden.
Die Verwendung bestimmten Operationen in lokalen Schnittstellenabfragen setzt das bedarfsgesteuerte Verhalten jedoch außer Kraft. In diesen Fällen werden die Abfrageergebnisse wie die Ergebnisobjektgruppen von fernen Schnittstellenabfragen vollständig im Speicher abgelegt. Beispiel für einen solchen Fall:
select e.myBusinessMethod( ) from EmpBean e where e.salary < 50000 order by 1 desc
Diese Abfrage erfordert, dass eine EJB-Methode die endgültige Ergebnisobjektgruppe erzeugt. Das gesamte Datensammlung aus der Datenbank muss demzufolge in einer Objektgruppe an den Speicher des Anwendungsservers zurückgegeben, wo dann die EJB-Methode für die Datensammlung in ihrer Gesamtheit ausgeführt werden kann. Aus diesem Grund sind Operationen von lokalen Schnittstellenabfragen, die EJB-Methoden aufrufen, generell nicht bedarfsgesteuert. Die Größe der zurückgegebenen Objektgruppe kann bei derartigen Abfragen nicht gesteuert werden.
Da lokale Schnittstellenabfragen ansonsten bedarfsabhängig sind, können Sie bei allen anderen Abfragen dieser Art die Größe der zurückgegebenen Objektgruppen steuern. Nach Abruf der gewünschten Anzahl von Rückgabewerten aus der Datenbank können Sie die Abfrageschleife mit einem Aufruf der Methode "close()" für das Objekt "QueryLocalIterator" schließen. Andernfalls werden die zum Ausführen der EJB-Abfrage verwendeten SQL-Cursor erst geschlossen, wenn sich die gesamte Ergebnisobjektgruppe im Speicher befindet oder die Transaktion endet.