IBM Optim pureQuery Runtime

IBM® Optim pureQuery Runtime proporciona JPA (Java™ Persistence API) con un modo alternativo de acceder a una base de datos. PureQuery es compatible con SQL (Structured Query Language) estático. PureQuery solo está soportado por los proveedores de persistencia OpenJPA y WSJPA.

Acerca de esta tarea

JPA en entornos Java EE y Java SE proporciona un soporte opcional para el entorno de ejecución de pureQuery. PureQuery es una plataforma de acceso a datos Java de alto rendimiento que ayuda a gestionar aplicaciones que acceden a datos. PureQuery proporciona un conjunto de API alternativas que se pueden utilizar, en lugar de JDBC (Java Database Connectivity), para acceder a las bases de datos DB2 e Informix.

Para utilizar esta característica en el servidor de aplicaciones, debe instalar Data Studio pureQuery Runtime versión 1.2 o posterior. Si tiene previsto ejecutar el mandato bind de DB2 desde la consola administrativa o con la herramienta wsadmin, debe disponer de pureQuery v1.2 o posterior. Consulte el tema del Information Center de IBM Optim pureQuery Runtime sobre la instalación de pureQuery Runtime para obtener más información.

Puede utilizar pureQuery de forma dinámica. La ubicación del archivo pdqxml se especifica mediante la propiedad pdqProperties en el URL de conexión o de origen de datos. Para obtener más información, consulte el tema sobre la utilización de pureQuery en modalidad dinámica.

PureQuery utiliza paquetes de DB2. Estos paquetes contienen información sobre una o más sentencias SQL y se almacenan en el catálogo de DB2. Para crear los paquetes, el usuario debe ejecutar primero el mandato wsdbgen en una aplicación JPA. El mandato wsdbgen crea un archivo nombre_unidad_persistencia.pdqxml. Este archivo contiene sentencias SQL pregeneradas para Create, Update, Delete y Retrieve, NamedQueries y NamedNativeQueries de entidades JPA. EL archivo nombre_unidad_persistencia.pdqxml debe enlazarse a la base de datos. Los paquetes de DB2 asociados se generan y la sentencia SQL se inicia de forma estática en tiempo de ejecución. Este archivo nombre_unidad_persistencia.pdqxml debe estar incluido en el archivo JAR (Java Archive) de la aplicación.

El servidor de aplicaciones ofrece soporte para SQL estático para beans de entidad Enterprise JavaBeans (EJB) 2.x y posterior con la opción ejbdeploy SQLj. Con JPA, esta función se ofrece a través de pureQuery.

Hay varias ventajas en el uso de pureQuery, en lugar de JDBC y SQLJ. El SQL estático ofrece una mayor seguridad y control sobre el acceso a los datos porque sólo se otorga autorización a las aplicaciones para ejecutar SQL conocido. El SQL estático permite utilizar mejor los recursos del servidor de DB2 porque evita el análisis en tiempo de ejecución y la optimización de las sentencias SQL.

Al realizar el proceso de enlazado y al definir el proveedor JDBC, los siguientes cuatro archivos JAR (Java Archive) deben estar en la classpath:
  • db2jcc_license_cisuz.jar
  • db2jcc_license_cu.jar
  • pdq.jar
  • pdqmgmt.jar
Atención: Consulte más información acerca del nivel de conformidad JAR de DB2 para pureQuery en el sitio web de soporte de IBM: Requisitos del sistema para IBM Optim pureQuery Runtime for Linux, UNIX y Windows.
Restricción:
  • No se da soporte para la propiedad QueryTimeout especificada a través de la API FetchPlan o a través de la serie de plug-in para wsjpa.ConnectionFactoryProperties. El valor QueryTimeout se ignora si se especifica.
  • No se da soporte a la propiedad QueryTimeout especificada mediante la API FetchPlan. El valor QueryTimeout se ignora si se especifica.
  • El proceso de resultados de gran tamaño de OpenJPA utiliza las API JDBC para cursores desplazables.
Importante:
  • JPA establece la propiedad pureQuery, pdq.executionMode, en el valor STATIC.
  • Además del archivo JAR del controlador JDBC, la configuración de proveedor de JDBC debe incluir el archivo JAR para el entorno de tiempo de ejecución pureQuery.
  • OpenJPA proporciona soporte para que los programas de aplicación accedan mediante programación y alteren FetchPlan durante el tiempo de ejecución. La modificación del plan de captación puede generar un SQL que no haya sido generado por el mandato wsdbgen durante la compilación de la aplicación. Si esto sucede, el SQL se ejecuta dinámicamente, en lugar de utilizar el SQL estático del paquete de base de datos.
  • Si el usuario realiza cambios en las consultas de aplicación, la correlación de entidades o las propiedades de persistencia, vuelva a ejecutar el mandato wsdbgen y el mandato bind. Este proceso genera y enlace los paquetes de base de datos actualizados.
  • Los valores de parámetros de entrada de las consultas JPA (tanto con consultas SQL de EJB como con consultas SQL nativas) no pueden ser valores NULL, excepto en el caso de valores de expresión SET de sentencias de actualización. Para buscar valores NULL en una cláusula WHERE de SELECT, UPDATE o DELETE, entre, en cambio el predicado is null.

Procedimiento


Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_jpapdq
File name: tejb_jpapdq.html