![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Comparaison des services de requête EJB dynamique et de déploiement
Le service de requête dynamique permet de créer et d'exécuter des requêtes portant sur des beans entity créés dynamiquement lors de l'exécution et non pas définis lors du déploiement. Avec la requête dynamique, les requêtes définies lors de l'exécution sont beaucoup plus souples et tirent parti de la puissance du langage Enterprise JavaBeans (EJB)-Query Language (QL). En plus des fonctionnalités offertes par les requêtes en langage EJB-QL, les requêtes dynamiques prennent en charge des fonctions que ne fournissent pas les requêtes statiques standard. Il s'agit par exemple de la possibilité de sélectionner plusieurs champs de données directement à partir d'un bean (une seule sélection est possible avec les requêtes statiques) et d'exécuter des méthodes métier directement dans la requête.
Les requêtes dynamiques permettent de créer des applications plus efficaces et moins coûteuses en termes de ressources. Par exemple, il est nécessaire pour cela de connaître les données contenues dans deux champs de l'ensemble de résultats d'une requête. Etant donné qu'une requête EJB-QL standard ne peut sélectionner qu'un seul champ, il convient de sélectionner l'objet EJB tout entier et d'extraire les donnés requises dans l'ensemble de résultats renvoyé par le biais des méthodes d'accès aux données, ce qui peut consiste à franchir les limites d'une CMR (Container Managed Relationships). En revanche, lorsque vous utilisez une requête dynamique, ces deux types d'informations sont extraites par la requête sans qu'il soit nécessaire de franchir les limites d'une CMR ou de faire appel à des méthodes d'accès. C'est en fonction de ce cela qu'il convient de déterminer si l'utilisation d'une requête dynamique est susceptible ou non d'améliorer les performances. Il faut prendre en compte le volume de données à extraire ainsi que les processus à mettre en oeuvre pour y parvenir, tels que le franchissement des limites d'une CMR ou l'utilisation des méthodes d'accès.
L'utilisation de paramètres à la place de valeurs littérales a également une incidence sur les performances. Dans la plupart des cas, il est préférable de définir des valeurs conditionnelles en tant que paramètres dans la requête et de transmettre ensuite ces derniers selon des méthodes appropriées. Vous avez ainsi plus de chances de trouver un plan de requête approprié dans la mémoire cache et il n'est alors plus nécessaire d'analyser et de créer un plan de toutes pièces. Par exemple, l'instruction "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE foo" est mieux formulée que "SELECT Object(o) FROM schemaname AS o WHERE o.fieldname LIKE ?1", avec la valeur foo transmise en tant que paramètre à la méthode executeQuery. En procédant ainsi, toutes les requêtes dynamiques exécutées ultérieurement ayant la même structure mais des conditions littérales de type chaîne différentes, sont enregistrées en tant que réussite en mémoire cache, ce qui a incidence sur les performances "observées".
Lorsque la requête dynamique est utilisée comme substitut exact d'une requête statique équivalente, son exécution prend environ 25% de temps supplémentaire qu'une requête statique. Il convient en effet non seulement d'exécuter la requête mais aussi d'analyser et de créer un plan. En ce qui concerne les requêtes statiques, ce coût en ressources est sensible lors du déploiement. Cependant, la mise à disposition de nouvelles fonctions par le biais des requêtes dynamiques, et notamment la possibilité de sélectionner plusieurs champs de données dans une seule requête y compris dans des CMR différentes, permet d'obtenir des performances accrues.