Remarques sur les performances des requêtes dynamiques
Même si une requête dynamique peut se révéler très pratique, elle peut parfois avoir un impact sur les performances de votre application.
General performance considerations
Une requête dynamique comporte les éléments suivants, qui sont susceptibles de diminuer les performances de votre application :
- Convertisseurs de types de données et méthodes Java™
En règle générale, les opérations et les prédicats des requêtes sont convertis en SQL pour que le serveur de base de données puisse les exécuter. Toutefois, si la requête inclut des convertisseurs de types de données (pour le mappage d'EJB vers RDB, par exemple) ou des méthodes Java, les opérations et les prédicats associés de la requête doivent être exécutés dans la mémoire du serveur d'applications.
- Méthodes EJB et critères appelant le renvoi de références d'EJB
Les requêtes qui intègrent ces éléments déclenchent l'activation totale des EJB dans la mémoire du serveur d'applications (le renvoi d'une liste de zones CMP à partir d'une requête n'entraîne pas l'activation d'un EJB).
Lorsque vous évaluez les performances d'une application, vous devez également tenir compte du partage des connexions par les requêtes dynamiques avec le gestionnaire de persistance. Ainsi, une application qui inclut des méthodes finder, une navigation CMR et des requêtes dynamiques repose sur une connexion partagée unique entre le gestionnaire de persistance et le service de requête dynamique pour exécuter des tâches.
Limiting the return collection size
- Remote interface queries: The QueryIterator class of the remote interface mandates that all of
your query results materialize in application server memory over the course of one method call. Le ou les curseurs SQL employés pour
exécuter la requête EJB sont fermés à la fin de cet appel. Ce
comportement risque d'entraîner la création de goulots d'étranglement
dans le serveur de base de données. Vous devez donc limiter la taille
des collections de résultats susceptibles d'être importantes.
- Local interface queries: In most situations, the QueryLocalIterator object behaves
as a wrapper around an SQL cursor. It is demand-driven; it causes data to be returned incrementally.
Pour chaque extraction d'enregistrement de la
base de données, la méthode next() doit être appelée sur l'itérateur.
Cependant, certaines opérations dans les requêtes de l'interface locale prennent le pas sur le comportement à la demande. Dans ce cas, les résultats de la requête se matérialisent complètement dans la mémoire, comme le font les collections de résultats des requêtes de l'interface distante. Par exemple :
select e.myBusinessMethod( ) from EmpBean e where e.salary < 50000 order by 1 desc
Cette requête requiert les performances d'une méthode d'EJB pour générer la collection de résultats finale. Par conséquent, la totalité de l'ensemble de données de la base de données doit être renvoyée en une seule collection dans la mémoire du serveur d'applications, où la méthode d'EJB peut être exécutée sur la totalité de cet ensemble de données. C'est pourquoi, les opérations de requêtes de l'interface locale appelant les méthodes d'EJB ne sont généralement pas à la demande. Il n'est pas possible de contrôler la taille de la collection renvoyée pour de telles requêtes.
Because they are demand-driven, all other local interface queries allow you to control the size of return collections. Vous pouvez utiliser un appel de la méthode close() sur l'objet QueryLocalIterator pour fermer la boucle de la requête une fois le nombre de valeurs renvoyées depuis le magasin de données atteint. Dans le cas contraire, le ou les curseurs SQL employés pour exécuter la requête EJB ne sont pas fermés tant que la totalité de l'ensemble de résultats ne s'est pas accumulée en mémoire ou que la transaction ne s'est pas terminée.