OutOfMemory caused by Leak in Open JPA

OutOFMemory in the SystemOut.log file and or seeing:

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
0xa57200e0                                                              
  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 close()ing 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.

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

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

That will then cause getting a set of traces with the specifications of: *=info:JPA=all:openjpa=all:WAS.j2c=all:RRA=all. In the traces, you will find something like the following:

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
0xa57200e0
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.) Vritually 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) - in fact, it that data structure is part of the EMF instance.) The above is the key signature of OPENJPA-2042.

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.