[ 
https://issues.apache.org/jira/browse/OPENJPA-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

brian yoder updated OPENJPA-2566:
---------------------------------
    Comment: was deleted

(was: It would seem that if I wrap my jpaEM with a try, catch, finally - and 
call the em.close() in the finally I don't get a leak.  However since I am 
using EJB 3x with an EntityManager injection I wonder why close must be called 
for every method invocation if the EM is reused by the EJB.

That said I think it's worth a look into the OpenJPA codebase to see why 
OpenJPAPersistance.cast(em) is causing a leak, and has to be manually closed at 
the end of the use of the casted EM.  I suspect that the EM is calling 
em.getDelegate(), and possibly that is part of the mystery here.  If this is a 
shared deligate, could that possibly explain the leak?

For my Glassfish J2EE server the em is actually this class:
com.sun.enterprise.container.common.impl.EntityManagerWrapper

    public static OpenJPAEntityManager cast(EntityManager em) {
        if (em instanceof OpenJPAEntityManager)
            return (OpenJPAEntityManager) em;
        return (OpenJPAEntityManager) em.getDelegate();
    }



)

> Memory leak when using OpenJPAPersistence.cast(em)?
> ---------------------------------------------------
>
>                 Key: OPENJPA-2566
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2566
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 2.3.1
>            Reporter: brian yoder
>         Attachments: screen shot OOM.jpg
>
>
> I have noticed a memory leak when using the following code on Glassfish J2EE 
> server 3.1, however suspect the issue is not related to Glassfish.
> OpenJPAEntityManager kem = OpenJPAPersistence.cast(emNoTran);
> kem.getFetchPlan().addFetchGroup("contactDetails");
> It seems the code causes a huge memory leak with JDBCBrokerFactory growing 
> its MapBackedSet, ConcurrentHashMap.
> Any ideas why this would be?  I am calling the above code over-and-over again 
> for each EJB method invocation, which it was my understanding it is only good 
> for the current EM transaction.  Perhaps I have misunderstood.
> My Requirement is to set the fetch group only for the current transaction, 
> such that lazy fields for a particular entity get loaded up front, but only 
> within this call from the EJB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to