Tab navigation

• Learning more
• Troubleshooting- selected tab,
• Collecting data

Troubleshooting Common JPA Issues

Please review the link below for some common JPA issues: 

Troubleshooting JPA applications

For other common issues not addressed by the link above, check the following list:

1. Migrating JPA Providers (OpenJPA <-> EclipseLink)
   • Many customers report issues centered around migrating their applications from OpenJPA -> EclipseLink (migrating to WAS v9).  This link documents common migration issues:
     Java™ Persistence API 2.1 behavior changes 
   • EclipseLink also has a wiki page that contains several points to take into consideration when migrating from OpenJPA -> EclipseLink.  This link documents those points:  EclipseLink/Examples/JPA/Migration/OpenJPA
   • A possible solution/workaround would be to revert to OpenJPA as the default provider.
2. Using Hiberate as a Third-Party Provider
   • Using a third-party persistence provider is supported and one common use case is to use Hibernate as the new persistence provider.  We have documentation here for how to package your application and configure the third-party provider:  Using third-party persistence providers
   • One very common issue for this use case is the packaging of JPA Persistence API bundles in the application.  If done, this will conflict with the JPA API bundles that are shipped with WAS.  For example, Hibernate has "hibernate-jpa-2.1-api-1.0.0.Final.jar" as a required bundle.  However, this bundle is a repackage of the javax.persistence API and will conflict with what we ship within WAS.
3. Common causes of the OutOfMemoryException
   • For large/complex object-relationship models (ORM)
     • For new applications or high load applications, you may need to allocate larger amounts of memory to your JVM if you are seeing large amounts of memory consumed.
       • Increase max heap size
   • Persistence units that use DataSources with JNDI names utilizing resource references (that is, using the java:comp/env namespace) exist (transparently to the application) with a multiplicity equal to the number of unique binding namespaces that resource ref is associated with.  Care should be taken because each separate EMF created has its own unique data cache not shared with others even of the same persistence unit definition.
   • L1 (persistence context) cache memory usage
     • Be mindful of memory consumption by large objects (BLOBs and CLOBs)
     • If you have a large result set from a query, this can consume a lot of memory
       • EclipseLink Pagination
       • OpenJPA Large Result Sets
     • Improper management of EntityManagers
       • An application is responsible for managing the entities actively managed by the persistence context (this will keep them from being garbage collected).  For long-living persistence contexts (application managed or extended container managed) an application may need to make judicious use of EntityManager.clear() and EntityManager.detach() to manage its memory usage.
   • Configure persistence provider L2 cache to improve memory usage
     • EclipseLink Cache Configuration
     • OpenJPA Cache Configuration
4. Specific JPA providers have support for specific JPA levels. 
   • Make sure the third-party JPA provider version you are using supports the configured JPA specification level
     • For example, different versions of Hibernate support different JPA spec levels
       • JPA 2.0: Hibernate 3.5-4.2
       • JPA 2.1: Hibernate 4.3-5.2