OutOfMemory caused by Leak in Open JPA

Technote (troubleshooting)


After using an application for some time you will begin to see slowness in the application and eventually you will see an OutOfMemory exception in the systemOut.log file for the WebSphere Application Server.


OutOfMemory in the SystemOut.log and or seeing in the heap dump analysis tool:

632,175,672 (79.22%) [32] 20 class                            
org/apache/openjpa/enhance/PCEnhancer 0xa570f250                        
 632,174,752 (79.22%) [32] 6 class org/apache/openjpa/enhance/PCRegistry
  632,170,336 (79.22%) [24] 1 java/util/LinkedList 0xa57cd600

Message in the trace file for JPA.


The problem arises with applications that do not use injection (ie, @PersistenceContext or @PersistenceUnit) to obtain JPA resources. Instead, the applications use javax.persistence.Persistence.getEntityManagerFactory(). While this is not forbidden, it is not a good practice. The reason that it is not a good practice is that the application developer is the one responsible for closing the EMF once it is no longer necessary. Garbage collecting an EMF does not automatically close it. There is no Finalizer that will do that for the application. Another reason that this is not a good practice is because creating a EMF is an expensive process, a better performing application will create and cache an EMF (pretty much automatically done if you use injection), and use the cached EMF to create an EntityManager (EM) and dispose of it once the transaction is complete.

So if an application creates an EMF via Persistence.createEMF() and does not close it, you will get the above leak. This is because the PCRegistry (before the OJ-2042 alteration) maintained a strong reference to the listener data structure. This link is removed only when an EMF is properly closed. So when EMFs are GC'd without being properly closed, the refs to these data structures will accumulate until the heap is exhausted.

This has been the case for 100% of the above signature.

Diagnosing the problem

When using the IBM Heap Dump Analyzer you will see something like the following.

Since this is an OOM problem, it seems likely that this is something in the JVM initially, so you will get Java cores/dumps and see entries like the one above.

When reviewing the java cores/dumps with the Heap Analyzer Tool , the following leak suspect will surface for this issue:

632,175,672 (79.22%) [32] 20 class
org/apache/openjpa/enhance/PCEnhancer 0xa570f250
632,174,752 (79.22%) [32] 6 class org/apache/openjpa/enhance/PCRegistry
632,170,336 (79.22%) [24] 1 java/util/LinkedList 0xa57cd600

Look at the dump above. You see PCRegistry, a class from OpenJPA, occupying a significant chunk of the heap (79% in this case). Virtually all of that heap is retained by its LinkedList member - that linked list is a list of Listeners (where a listener is a data structure that is a one-to-one mapping with an EntityManagerFactory (EMF) - if that data structure is part of the EMF instance.)

The above is the key signature of OPENJPA-2042:

Resolving the problem

Use injection (ie @PersistenceContext or @PersistenceUnit) to obtain JPA resources rather than the above or the fix provided by OJ-2042 (delivered by PM64489 and PM64591) works around this issue by changing the PCRegistry's reference to the listening data structure from a strong to weak reference. This allows the application server to tolerate the fact that these EMFs are not getting properly closed.

Related information

JPA System Properties
Troubleshooting JPA Applications
Troubleshooting contents and dependency injection

Rate this page:

(0 users)Average rating

Add comments

Document information

More support for:

WebSphere Application Server
Java Persistence API (JPA)

Software version:

6.1, 7.0, 8.0, 8.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Software edition:

Feature Pack for EJB 3.0

Reference #:


Modified date:


Translate my page

Machine Translation

Content navigation