Resolución de problemas de las aplicaciones JPA
Utilice esta información para encontrar los diferentes problemas conocidos de las aplicaciones JPA (Java™ Persistence API).
Procedimiento
- Solucione los problemas de NoClassDefFoundError para
las clases org.apache.openjpa.*
o com.ibm.websphere.persistence.* cuando utilice el jar del
cliente ligero de JPA.
A partir de WebSphere Application Server Versión 9.0, existen dos archivos JAR de cliente ligero JPA disponibles. com.ibm.ws.jpa-2.1.thinclient_9.0.jar: incluye interfaces de especificación JPA 2.1, así como clases e interfaces EclipseLink. com.ibm.ws.jpa-2.0.thinclient_9.0.jar: incluye interfaces de especificación JPA 2.0, así como clases e interfaces WSJPA y OpenJPA. Antes de la versión 9, este jar se llamaba com.ibm.ws.jpa_X.X.jar.
Avoid trouble:
Si la aplicación depende de clases o el comportamiento específicos OpenJPA o WSJPA y ha añadido com.ibm.ws.jpa-2.1.thinclient_9.0.jar a la classpath, deberá utilizar el com.ibm.ws.jpa-2.0.thinclient_9.0.jar en la classpath del cliente ligero en su lugar.
gotcha - Solucione problemas de NoClassDefFoundError para las clases
org.apache.openjpa.*
o com.ibm.websphere.persistence.* de una aplicación que se ejecuta en
un servidor WebSphere Application Server. En WebSphere Application Server versión 9.0, el proveedor de persistencia predeterminado para los perfiles nuevos se ha cambiado de OpenJPA a EclipseLink. Si ejecuta una aplicación OpenJPA cuando WebSphere está configurado para utilizar EclipseLink, generará un NoClassDefFoundError porque las clases OpenJPA no están disponibles en el tiempo de ejecución del servidor cuando se configuran para utilizar JPA 2.1.Nota: Si utiliza las herramientas de migración de WebSphere Application Server Versión 8.5.5 para migrar a WebSphere Application Server Versión 9.0, el nivel JPA se establecerá en 2.0 automáticamente, que utilizará el mismo proveedor JPA que en WebSphere Application Server versión 8.5.5.
Para resolver el problema, reconfigure el servidor o el clúster para utilizar JPA 2.0. Esto establece OpenJPA como el proveedor de persistencia predeterminado.
- Solucione el problema NoClassDefFoundError:
org.apache.openjpa.enhance.PersistenceCapable. Las
aplicaciones que utilizan OpenJPA pueden ejecutar herramientas de
mejora de tiempo de compilación en clases de entidad. El uso de la
mejora de OpenJPA añade referencias a clases, como
org.apache.openjpa.enhance.PersistenceCapable a la clase compilada. En WebSphere Application Server Versión 9.0, el proveedor de persistencia predeterminado para nuevos perfiles ha cambiado de OpenJPA a EclipseLink. Si intenta ejecutar una aplicación mejorada de OpenJPA cuando WebSphere Application Server se ha configurado para utilizar EclipseLink, generará un NoClassDefFoundError porque las clases OpenJPA no están disponibles en el tiempo de ejecución del servidor cuando está configurado para utilizar JPA 2.1Nota: Si utiliza las herramientas de migración de WebSphere Application Server Versión 8.5.5 para migrar a WebSphere Application Server Versión 9.0, el nivel JPA se establecerá en 2.0 automáticamente, que utilizará el mismo proveedor JPA que en WebSphere Application Server versión 8.5.5.Para resolver el problema, puede:
- Reconfigurar el servidor o clúster para utilizar JPA 2.0. Esto establece OpenJPA como el proveedor de persistencia predeterminado.
- Recompilar la aplicación y mejorar las entidades utilizando la mejora de EclipseLink, en lugar de la mejora de OpenJPA.
- Revise los mensajes relacionados con las transacciones.
En determinadas condiciones, es posible que se registre un mensaje como el siguiente: No se puede ejecutar {0} en una transacción gestionada WebSphere. WebSphere no da soporte a la manipulación directa de transacciones gestionadas.
Este puede ser debido a que no se ha configurado correctamente un origen de datos como <non-jta-data-source>. Consulte el tema del Information Center Asociación de proveedores de persistencia y orígenes de datos sobre cómo configurar un origen de datos para utilizarlo como <non-jta-data-source>.
- Resolución de problemas de clases que no se han ampliado en tiempo de
ejecución.
Es difícil diagnosticar estas situaciones. Algunas veces, puede encontrar que el problema es debido a que no se ha realizado la ampliación OpenJPA de las clases de entidades. Pueden detectarse ejemplos de esta situaciones cuando las entidades no tienen capacidad de persistencia. Busque un mensaje como el siguiente en el registro: Esta configuración no permite la optimización en tiempo de ejecución, pero los siguientes tipos listados no se han ampliado en tiempo de compilación ni durante la carga de las clases con un agente Java: "{0}".
Este mensaje indica que la ampliación en tiempo de ejecución prevista no se ha llevado a cabo en los tipos de entidades listadas. En la mayoría de los casos, este error simplemente es un error de tiempo de compilación y es necesario ejecutar PCEnhancer en las clases listadas. También puede indicar un problema más implicado, sobretodo si espera que la transformación del cargador de clases del contenedor realice la ampliación de entidades.
- Cuestiones de resolución de problemas con los cursos cerrados. La siguiente es una excepción de DB2 situada en el registro cronológico org.apache.openjpa.persistence.PersistenceException:
[ibm][db2][jcc][10120][10898] Operación no válida: el conjunto de resultados está cerrado y puede representar un problema de configuración de WebSphere Application Server.
De manera predeterminada, el servidor de aplicaciones configura la propiedad personalizada resultSetHoldability con un valor de 2 (CLOSE_CURSORS_AT_COMMIT). Esta propiedad hace que DB2 cierre resultSet/cursor en los límites de transacciones. Aunque el valor predeterminado de DB2 para resultSetHoldability sea 1 (HOLD_CURSORS_OVER_COMMIT), el servidor de aplicaciones retiene el valor predeterminado 2 para no interrumpir las compatibilidades con los releases anteriores del servidor de aplicaciones. Puede cambiar el valor predeterminado.Atención: Si este origen de datos es un origen de datos XA, defina una propiedad personalizada nueva en el origen de datos donde nombre_propiedad= downgradeHoldCursorsUnderXa y valor booleano = true.Avoid trouble: En la versión 8.0, si se utiliza un origen de datos DB2 XA, se exige la configuración siguiente para superar el problema de conjunto de resultados cerrado:
- Utilice DB2 Versión 9.1 FP4 (para el APAR IZ18072) o una versión posterior.
- Añada la propiedad personalizada name="downgradeHoldCursorsUnderXa", value="true" y type="java.lang.Boolean".
- Añada la propiedad personalizada name="resultSetHoldability", value="1" y type="java.lang.Integer".
- Evite que se utilice EntityManager en varias hebras. Si se genera una excepción con el texto de mensaje siguiente, es posible que esté permitiendo
accidentalmente que se utilice un EntityManager en varias hebras.
Para la especificación JPA, los EntityManagers se han de utilizar en una sola hebra. Es posible que reciba un mensaje de excepción como el siguiente (en este contexto, los intermediarios y EntityManagers son esencialmente lo mismo):Hay varios modos de solucionar este problema:
Varias hebras simultáneas han intentado acceder a un solo intermediario. De forma predeterminada, los intermediarios no tienen seguridad de hebras. Si necesita y desea que más de una hebra acceda a un intermediario, establezca la propiedad openjpa.Multithreaded en true para alterar temporalmente el comportamiento predeterminado.
Best practice: Utilice el patrón obtener-utilizar-cerrar cuando utilice los contextos de persistencia (ampliados) gestionados por la aplicación. Recuerde que debe cerrar EntityManager antes de dejar el método que ha utilizado EntityManager. Al dejar EntityManager abierto, puede permitir accidentalmente que otras hebras utilicen la misma instancia de EntityManager al mismo tiempo y consuman recursos del sistema. bprac
- Cambie la aplicación para que utilice los contextos de persistencia gestionados por contenedor insertando la instancia de EntityManager mediante la anotación @PersistenceContext, si el modelo de programación de la aplicación permite este cambio. Básicamente, esto aplica el patrón obtener-utilizar-cerrar ya que permite que el contenedor realice la gestión.
- Como se ha documentado en el texto de esta excepción, una solución rápida es configurar OpenJPA para requerir
acceso de varias hebras a los EntityManager en la propiedad openjpa.Multithreaded. La habilitación de esta propiedad puede
introducir una sobrecarga innecesaria.
Avoid trouble: Las variables de instancia para los servlets las comparten automáticamente todas las instancias del servlet. Si se utiliza la anotación @PersistenceContext en una variable de instancia de servlet pued resultar que accidentalmente varias hebras accedan al mismo EntityManager. Además, los EntityManager inyectados de esta forma no los limpia el contenedor hasta que se detiene la aplicación. Para servlets, es una opción mejor utilizar la anotación @PersistenceUnit para inyectar una EntityManagerFactory. gotcha
- Si utiliza bloqueo optimista, tenga en cuenta las condiciones de versión.
En la arquitectura JPA, el proveedor de persistencia utiliza la propiedad de versión para realizar bloqueo optimista y semántica de concurrencia
para una entidad persistente; por ejemplo:
@Entity public class VersionedTimestampEntity { @Id private int id; @Version private java.sql.Timestamp version; .... }
El proveedor actualiza la propiedad de versión en un valor nuevo cuando se graba la base de datos. Durante una operación de fusión de entidades, el proveedor de persistencia examina esta propiedad de versión para determinar si la entidad que se está fusionando es una copia obsoleta de la entidad. Si la operación ha fallado debido a que la condición de la versión es obsoleta, se generará una excepción OptimisticLockException. La propiedad de versión puede ser uno de estos tipos:- int
- Integer
- short
- Short
- long
- Largo
- Timestamp.
Si se persiste una entidad y, a continuación, se capta y actualiza en un contexto de persistencia diferente contenido en la ventana de precisión de la plataforma, el proveedor de persistencia no podrá detectar el bloqueo optimista y la condición concurrente. Como resultado, es posible que no se genere una excepción OptimisticLockException y que la integridad de los datos resulte comprometida.Avoid trouble: Si utiliza el tipo Timestamp para la propiedad de versión, la aplicación debe tener en cuenta el comportamiento que se puede mostrar debido a la precisión de la implementación que se utiliza para crear el objeto Timestamp. La implementación típica utiliza el método System.currentTimeMills. La precisión de tiempo de este método es específica de la plataforma. Por ejemplo, la precisión es de 15 ms para Windows de 32 bits y de 2 ms para z/OS.gotcha
- Resolución de la violación de restricciones de base de datos cuando trabaje con entidades.
Los proveedores JPA que se incluyen con WebSphere Application Server utilizan un gestor de actualización de restricción para determinar el orden de las solicitudes SQL en la base de datos basada en las configuraciones de entidad. Este gestor de actualización puede reorganizar el orden de las solicitudes SQL a la base de datos. Esto alivia a una aplicación en el sentido de que no tiene que saber el orden de las operaciones del gestor de entidades necesarias para llevar a cabo su lógica empresarial y optimiza el rendimiento de la base de datos utilizando el soporte de lotes subyacente.
Como el proveedor JPA no presupone que hay restricciones de base de datos implícitas para relaciones entre entidades, si hay restricciones en la base de datos, por ejemplo, una restricción de clave foránea, es posible que el proveedor JPA no emita las sentencias SQL en el orden deseado. En estas condiciones, es posible que se produzca la siguiente excepción o una similar:com.ibm.db2.jcc.b.SqlException: DB2 SQL error: SQLCODE: -530, SQLSTATE: 23503, SQLERRMC: xxxxxx
Hay varios modos de solucionar este problema:- El proveedor OpenJPA se puede configurar para leer información de
restricciones de la base de datos y aplicarla en el gestor de
actualizaciones durante el tiempo de ejecución añadiendo la propiedad
de configuración siguiente a la unidad de persistencia.
<property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)" />
- La aplicación puede mejorar la entidad para que utilice la anotación @ForeignKey para indicar
al proveedor JPA qué relaciones de clave foránea tienen restricciones.
public class Person { @ManyToOne @ForeignKey private Address address; .... }
- Para aplicaciones OpenJPA, la aplicación puede asumir la
responsabilidad de ordenar las sentencias SQL añadiendo la propiedad
de configuración siguiente a la unidad de persistencia.
<property name="openjpa.jdbc.UpdateManager" value="operation-order" />
Con esta opción de configuración presente, el proveedor JPA inicia las sentencias SQL en el mismo orden en que las han solicitado las operaciones de entidad. La aplicación debe tener presente las interdependencias entre entidades.
Avoid trouble: Aunque puede tener tendencia a utilizar una combinación de estas propiedades, debe utilizar sólo la que mejor se ajuste a su situación. Si se halla en una situación en que cree que sí es necesario utilizar una combinación de estas propiedades, tenga en cuenta que si utiliza ambas propiedades, openjpa.jdbc.UpdateManager y openjpa.jdbc.SchemaFactory, el resultado podría no ser de la petición de solicitud SQL necesaria para solucionar la excepción. El valor operation-order para la propiedad openjpa.jdbc.UpdateManager indica al proveedor JPA que desea realizar las solicitudes SQL en el orden que se han especificado en la aplicación. Aunque especifique la propiedad openjpa.jdbc.SchemaFactory, junto con el mandato openjpa.jdbc.UpdateManager, el proveedor JPA respeta la orden de la solicitud SQL especificada en una aplicación en lugar de ordenar automáticamente las solicitudes SQL para cumplir una restricción detectada como, por ejemplo, una restricción de clave foránea. Cuando se especifica la propiedad openjpa.jdbc.UpdateManager, es responsabilidad del desarrollador de aplicaciones asegurarse de que las solicitudes SQL se especifiquen en el orden correcto dentro de una aplicación. gotcha
- Eliminar las restricciones de la base de datos.
- El proveedor OpenJPA se puede configurar para leer información de
restricciones de la base de datos y aplicarla en el gestor de
actualizaciones durante el tiempo de ejecución añadiendo la propiedad
de configuración siguiente a la unidad de persistencia.
- Resolución de problemas utilizando la tarea de ANT OpenJPA MappingTool.
La tarea de ANT MappingTool que OpenJPA proporciona utiliza un cargador de clases temporal para cargar las clases de controlador JDBC. Este cargador de clases temporal podría tener problemas al cargar algunos controladores JDBC, como DB2.
Cuando ejecute la tarea ANT MappingTool, verá un error similar al siguiente:
[mappingtool] java.lang.UnsatisfiedLinkError: com/ibm/jvm/Trace.initTrace([Ljava/lang/String;[Ljava/lang/String;)V [mappingtool] at com.ibm.jvm.Trace.initializeTrace(Trace.java:94) [mappingtool] at com.ibm.jvm.Trace.<clinit>(Trace.java:59) [mappingtool] at java.lang.J9VMInternals.initializeImpl(Native Method) [mappingtool] at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) [mappingtool] at java.lang.Class.forNameImpl(Native Method) [mappingtool] at java.lang.Class.forName(Class.java:136) [mappingtool] at com.ibm.db2.jcc.a.o.n(o.java:577) [mappingtool] at com.ibm.db2.jcc.a.o.<clinit>(o.java:329)Para utilizar la herramienta de correlación, puede inhabilitar el cargador de clases temporal añadiendo el argumento tmpClassLoader=false a la tarea ANT. A continuación se muestran dos scripts de ejemplo de ANT:
En este ejemplo se muestra el problema:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.broken"> <mapping> <!-- esto muestra el problema --> . . . </mapping> </target>
En este ejemplo se evita el problema:
<taskdef name="mapping" classname="org.apache.openjpa.jdbc.ant.MappingToolTask" classpathref="jpa.cp"/> . . . <target name="map.fixed"> <mapping tmpClassLoader="false"> <!-- este funcionará --> . . . </mapping> </target>
- Impacto de DataCache en modelos de dominio de inconsistencia
Cuando una aplicación persiste en un modelo de dominio inconsistente y luego recupera las entidades en un contexto de persistencia aparte, las entidades recuperadas serán distintas, según si DataCache está activa o no.
Por ejemplo, pensemos en una relación bidireccional de uno a uno entre dos entidades correlacionadas por una columna de clave foránea única en la base de datos. Una aplicación puede establecer los campos de relación en las entidades de forma inconsistente. Cuando tales valores inconsistentes se correlacionan con la base de datos, los registros de la base de datos pasan a ser consistentes, sólo porque una columna de clave foránea única expresa que las relaciones bidireccionales de DataCache están activas; no obstante, DataCache captura los estados de entidad en memoria inconsistentes. Por lo tanto, cuando una aplicación persiste en un par de entidades relacionadas en una relación bidireccional pero sus campos de relación están establecidos en valores inconsistentes y más tarde recupera las entidades en un contexto de persistencia distinto, la relación bidireccional permanece inconsistente o bien pasa a ser consistente, según si se utiliza DataCache o no.
La correlación de varios campos con la misma columna pero que establecen valores distintos es otro ejemplo en el que el estado de entidad inconsistente es persistente pero recuperado como consistente en un contexto de persistencia aparte. En este caso, la introducción de DataCache también provocará que una entidad realizada en un contexto de persistencia aparte retenga valores distintos e inconsistentes mientras que sin DataCache una entidad mantendrá el mismo valor para ambos campos.
Best practice: Evitar rellenar el modelo de dominio de aplicación de forma inconsistente. Para OpenJPA, también es posible configurar la propiedad openjpa.InverseManager para detectar determinadas incoherencias como, por ejemplo, una relación bidireccional. bprac
- Resolución de problemas con MappingTool y la anotación @ForeignKey
con Sybase.
La herramienta de correlación OpenJPA no puede crear restricciones ForeignKey cuando se utiliza con Sybase Adaptive Server. Como resultado, las restricciones de clave foránea deben crearse manualmente.
- Resuelva los problemas de las opciones de configuración de DB2 Optim pureQuery Runtime. Si está utilizando DB2 Optim pureQuery Runtime con el proveedor WebSphere Application Server JPA (WSJPA), debe establecer la propiedad siguiente en el archivo persistence.xml:
<property name="openjpa.Compatibility" value="StrictIdentityValues=true"/>
Si necesita establecer una opción de compatibilidad diferente, por ejemplo, ReloadOnDetach=false, debe especificar ambas opciones como parámetros de la misma sentencia de propiedad en el archivo persistence.xml. Por ejemplo:
<property name="openjpa.Compatibility" value="StrictIdentityValues=true,ReloadOnDetach=false"/>
Avoid trouble: La propiedad de compatibilidad OpenJPA no elimina los tipos de proxy que genera OpenJPA para determinados tipos de datos, especialmente los tipos de fecha como, por ejemplo, GregorianCalendar. Esta omisión puede causar problemas con la deserialización. Si se produce un problema de deserialización, se emitirá un mensaje de error, parecido al siguiente:gotcha
El mensaje de error el: org.codehaus.jackson.map.JsonMappingException: No se puede construir la instancia de org.apache.openjpa.util.java$util$GregorianCalendar$proxy, problema: no se ha encontrado ningún método de creador en [Origen: org.apache.http.conn.EofSensorInputStream@d83fbd5; línea: 1, columna: 4094]
- Soluciones los problemas relacionados con los atributos de tipo relacionados con el tiempo en una entidad cuando utilice una base de datos con DB2 para z/OS. Si una entidad tiene un atributo de tipo relacionado con el tiempo, y la correspondiente columna correlacionada que está destinada a la base de datos no es compatible, la siguiente excepción puede ser observada en determinadas situaciones:
Es posible que vea esta excepción si:org.apache.openjpa.lib.jdbc.ReportingSQLException: THE DATE, TIME, OR TIMESTAMP VALUE 1 IS INVALID. SQLCODE=-18x, SQLSTATE=22007
- La base de datos está ejecutando DB2 para z/OS.
- Está utilizando una consulta con nombre y accede a la base de datos con SQL nativo.
- La consulta nativa utiliza el campo relacionado con el tiempo como un parámetro de SQL, pero la consulta no es compatible con la definición de columna para la tabla de la base de datos. Consulte el tema Conversiones de datos soportadas en el Centro de información de DB2 9.7 para obtener más información sobre la compatibilidad.
Subtopics
Registro de aplicaciones con JPA
El registro soporta la visualización, el rastreo y la resolución de problemas del comportamiento en tiempo de ejecución de una aplicación. Java™ Persistence API (JPA) proporciona un sistema de registro flexible que está integrado con el servidor de aplicaciones para ayudarle a resolver problemas.Resolución de problemas de puntos muertos de JPA y tiempos de espera excedidos de transacción
Los puntos muertos de base de datos y los tiempos de espera excedidos de transacción son el resultado de la contención entre dos o más clientes que intentan acceder al mismo recurso de base de datos. El punto muerto es un caso especial en el que se da una condición de bloqueo circular entre dos o más clientes, cada uno bloqueado por los demás, donde nadie puede continuar. Normalmente estos fenómenos no son errores de programación. Los provoca la lógica empresarial por el acceso a recursos de base de datos de forma compleja e interdependiente.Registro de aplicaciones con JPA
El registro soporta la visualización, el rastreo y la resolución de problemas del comportamiento en tiempo de ejecución de una aplicación. Java™ Persistence API (JPA) proporciona un sistema de registro flexible que está integrado con el servidor de aplicaciones para ayudarle a resolver problemas.Resolución de problemas de puntos muertos de JPA y tiempos de espera excedidos de transacción
Los puntos muertos de base de datos y los tiempos de espera excedidos de transacción son el resultado de la contención entre dos o más clientes que intentan acceder al mismo recurso de base de datos. El punto muerto es un caso especial en el que se da una condición de bloqueo circular entre dos o más clientes, cada uno bloqueado por los demás, donde nadie puede continuar. Normalmente estos fenómenos no son errores de programación. Los provoca la lógica empresarial por el acceso a recursos de base de datos de forma compleja e interdependiente.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_jpatroubleshoot
File name: tejb_jpatroubleshoot.html