Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] memory not released at end of transactions with TLE

JPA requires that by default in JSE an EntityManager has an extended
persistence context.  This means that it is required to maintained identity
and track changes to everything that you have ever read in the

So it is very much expected that it will continue to consume memory.

In JEE a JTA managed EntityManager will have a new persistence context per
JTA transaction, so will not consume memory, but will also not maintain
object identity, and you must re-read/find any objects across transaction

In JSE you should generally create a new EntityManager per transaction, or
per request.  If you have a long lived EntityManager you are responsible for
managing it using clear().

EclipseLink also has a feature that is an extension to JPA, that allows a
weak persistence context.  This will allow managed objects to garbage


Dies K wrote:
> I've run into an issue where the heap space usage keeps increasing. I
> can reproduce it with the simple code below.
> Could someone explain why this happens?
> I'm using TLE in GF v2.0UR1. The issue does not seem to occur on the
> EclipseLink v2.1 nightly.
> I run the following code in a Java SE application. I pass system
> property toplink.cache.shared.default=false to the Java VM to turn off
> the shared cache.
> EntityManager em = getEntityManager();
> for(i=0; i<3000; i++){
>   em.getTransaction().begin();
>   em.persist(new Entity());
>   em.getTransaction().commit();
> }
> Now when I add em.clear() after the commit() call in the loop, the
> memory usage stays stable.
> While debugging the cause of the difference in memory usage, I found the
> following:
> ==============================================================
> In synchronizeAndResume() of UnitOfWorkImpl, the Entity object to
> EntityManager.persist() is added to hashtable cloneMapping.
> oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl class
> protected IdentityHashtable cloneMapping;
>   public void synchronizeAndResume() {
>     ...
>         descriptor.getObjectChangePolicy().revertChanges(clone,
> descriptor, this, newCloneMapping);
>       ...
>     setCloneMapping(newCloneMapping);//Added here
>     ...
>   }
> * descriptor.getObjectChangePolicy() returns a
> DeferredChangeDetectionPolicy
> ==============================================================
> The hashtable cloneMapping is cleared when EntityManager.clear() is
> called, so the amount of heap space after the transactions is different
> depending on whether EntityManager.clear() is called or not.
> Is this the intended behavior? What is the purpose of not releasing the
> memory after a transaction even when the shared cache is disabled?
> According to the comment below in the source code, I assume this is a
> necessary processing when using DeferredChangeDetectionPolicy, but I
> don't exactly understand what it is for.
>     //Build backup clone for DeferredChangeDetectionPolicy or
> ObjectChangeTrackingPolicy,
>     //but not for AttributeChangeTrackingPolicy
> I tried 'blaming' this source file with svn to see if it was fixed in
> EclipseLink, but it appears James refactored this method as part of a
> number of seemingly unrelated issues and improvements so I'm still not
> sure whether this was just a bug.
> Thanks,
> Dies

----- James Sutherland
 EclipseLink ,
Wiki: EclipseLink , TopLink 
Forums: TopLink , EclipseLink 
Book: Java Persistence 
View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top