IBM Optim pureQuery Runtime
IBM® Optim pureQuery Runtime offre à l'API JPA (Java™ Persistence API) une autre manière d'accéder à une base de données. PureQuery prend en charge le langage SQL (Structured Query Language) statique. PureQuery est pris en charge uniquement par les fournisseurs de persistance OpenJPA et WSJPA.
Pourquoi et quand exécuter cette tâche
JPA dans les environnements Java EE et Java SE propose une prise en charge facultative de l'environnement d'exécution pureQuery. PureQuery est une plateforme d'accès aux données Java de haute performance qui aide à gérer les applications qui accèdent aux données. PureQuery fournit un autre ensemble d'API pouvant être utilisé à la place de JDBC (Java Database Connectivity) pour accéder à la base de données DB2 et Informix.
Pour utiliser cette fonction sur le serveur d'applications, vous devez installer Data Studio pureQuery runtime version 1.2 ou version ultérieure. Si vous prévoyez d'exécuter la commande de liaison DB2 à partir de la console d'administration ou avec l'outil wsadmin, pureQuery version v1.2 ou ultérieure doit être installé. Pour plus d'informations, voir la rubrique du centre de documentation IBM Optim pureQuery Runtime relative à l'installation de pureQuery Runtime.
Vous pouvez utiliser pureQuery dynamiquement. L'emplacement du fichier pdqxml est spécifié par la propriété pdqProperties sur la source de données ou l'URL de connexion. Pour plus d'informations, voir la rubrique relative à l'utilisation de pureQuery en mode dynamique.
PureQuery utilise des modules DB2. Ces modules sont composés d'informations sur une ou plusieurs instructions SQL et sont stockés dans le catalogue DB2. Pour créer les modules, l'utilisateur doit d'abord exécuter la commande wsdbgen sur une application JPA. La commande wsdbgen crée un fichier nom_unité_persistance.pdqxml. Ce fichier contient des instructions SQL pré-générées pour créer, mettre à jour, supprimer et extraire les requêtes NamedQueries et NamedNativeQueries des entités JPA. Le fichier nom_unité_persistance.pdqxml doit être associé à une base de données. Des modules DB2 sont générés et l'instruction SQL est démarrée statistiquement lors de l'exécution. Ce fichier nom_unité_persistance.pdqxml doit être inclus dans le fichier JAR (Java archive) de l'application.
Le serveur d'applications fournit une prise en charge du langage SQL statique pour les beans d'entité EJB (Enterprise JavaBeans) 2.x et versions ultérieures avec l'option ejbdeploy SQLj. Avec JPA, cette fonction est proposée via pureQuery.
L'utilisation de pureQuery à la place de JDBC et de SQLJ procure plusieurs bénéfices. Le langage SQL statique offre une sécurité et un contrôle supplémentaires sur l'accès aux données étant donné que les applications ne sont accessibles que pour exécuter un SQL connu. Le langage SQL statique offre une meilleure utilisation des ressources sur le serveur DB2 parce qu'il évite l'analyse syntaxique d'exécution et l'optimisation des instructions SQL.
- db2jcc_license_cisuz.jar
- db2jcc_license_cu.jar
- pdq.jar
- pdqmgmt.jar
- Il n'existe pas de prise en charge de la propriété QueryTimeout indiquée via l'API FetchPlan ou la chaîne de plug-in de la propriété pour wsjpa.ConnectionFactoryProperties. La valeur QueryTimeout est ignorée si cela est spécifié.
- Il n'existe pas de prise en charge de la propriété QueryTimeout indiquée via l'API FetchPlan. La valeur QueryTimeout est ignorée si cela est spécifié.
- Le traitement des résultats importants OpenJPA utilise des API JDBC pour les curseurs flottants.
- JPA affecte la valeur STATIC à la propriété pureQuery, pdq.executionMode.
- En plus du fichier JAR du pilote JDBC, la configuration du fournisseur de la connectivité JDBC doit inclure le fichier JAR pour l'environnement d'exécution pureQuery.
- OpenJPA propose une prise en charge afin de permettre aux programmes de l'application d'accéder et d'altérer le FetchPlan lors de l'exécution à l'aide d'un programme. L'altération du plan d'extraction peut engendrer un élément SQL qui n'a pas été généré par la commande wsdbgen lors de la phase de création de l'application. Si cela se produit, l'élément SQL est exécuté de manière dynamique au lieu d'utiliser un SQL statique provenant du module de base de données.
- Si l'utilisateur apporte des modifications aux requêtes de l'application, au mappage des entités ou aux propriétés de persistance, exécutez la commande wsdbgen et réalisez une nouvelle liaison. Ce processus génère et lie les modules de base de données mis à jour.
- Les valeurs du paramètre d'entrée dans les requêtes JPA (avec les requêtes SQL EJB et les requêtes SQL natives) ne peuvent pas être des valeurs NULL sauf en cas de valeurs d'expression SET d'instructions mises à jour. Pour rechercher les valeurs NULL dans une clause OU de SELECTIONNER, METTRE A JOUR ou SUPPRIMER, entrez le prédicat is null à la place.
Procédure
- En savoir plus sur Configuration des fournisseurs JDBC pour l'utilisation de pureQuery afin d'accéder à DB2.
- En savoir plus sur Configuration des fournisseurs JDBC pour l'utilisation de pureQuery afin d'accéder à Informix.
- En savoir plus sur Configuration des fournisseurs JDBC de source de données pour utiliser pureQuery dans un environnement Java SE.
- En savoir plus sur Utilisation de pureQuery en mode dynamique par rapport au mode statique pour DB2 et Informix.