[eclipselink-users] memory not released at end of transactions with TLE

[Dies Koper <diesk@xxxxxxxxxxxxxxxxxxx>]

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