[
https://issues.apache.org/jira/browse/OPENJPA-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294711#comment-14294711
]
brian yoder edited comment on OPENJPA-2566 at 1/28/15 5:00 AM:
---------------------------------------------------------------
So here are a few more things I noticed:
1) If I wrap my jpaEM in try, catch, finally - and call jpaEM.close() in the
finally, there is no leak.
2) If I call em.find() it doesn't fetch the lazy fields, but jpaEM.find() does,
so obvioursly there is a disconect using the cast.
3) My injected EM is a wrapper class from Sun (Glassfish).
This leads me to beleive that OpenJPAPersistence.cast(em) is actually returning
a different EM, it looks like the code calls em.getDelegate(), so I wonder if
that is a global EM or something? If so that explains this behavior.
/**
* Return the OpenJPA facade to the given entity manager.
*/
public static OpenJPAEntityManager cast(EntityManager em) {
if (em instanceof OpenJPAEntityManager)
return (OpenJPAEntityManager) em;
return (OpenJPAEntityManager) em.getDelegate();
}
I have the need to set a fetch group within a specific transaction/method, so
was basing my code on the OpenJPA sample:
Example 5.21. Adding an Eager Field
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
kem.getFetchPlan().addField(Magazine.class, "publisher");
Magazine mag = em.find(Magazine.class, magId);
But in Glassfish this will cause the memory leak when using EJB with injected
EM, unless you manually call close on kem...
I tried to do it by using the OpenJPAQuery cast, but that flat out doesn't work
in Glassfish:
java.lang.ClassCastException:
com.sun.enterprise.container.common.impl.QueryWrapper cannot be cast to
org.apache.openjpa.persistence.OpenJPAQuery
at
org.apache.openjpa.persistence.OpenJPAPersistence.cast(OpenJPAPersistence.java:70)
was (Author: byoder):
So here are a few more things I noticed:
1) If I wrap my jpaEM in try, catch, finally - and call jpaEM.close() in the
finally, there is no leak.
2) If I call em.find() it doesn't fetch the lazy fields, but jpaEM.find() does,
so obvioursly there is a disconect using the cast.
3) My injected EM is a wrapper class from Sun (Glassfish).
This leads me to beleive that OpenJPAPersistence.cast(em) is actually returning
a different EM, it looks like the code calls em.getDelegate(), so I wonder if
that is a global EM or something? If so that explains this behavior.
/**
* Return the OpenJPA facade to the given entity manager.
*/
public static OpenJPAEntityManager cast(EntityManager em) {
if (em instanceof OpenJPAEntityManager)
return (OpenJPAEntityManager) em;
return (OpenJPAEntityManager) em.getDelegate();
}
I have the need to set a fetch group within a specific transaction/method, so
was basing my code on the OpenJPA sample:
Example 5.21. Adding an Eager Field
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
kem.getFetchPlan().addField(Magazine.class, "publisher");
Magazine mag = em.find(Magazine.class, magId);
But in Glassfish this will cause the memory leak when using EJB with injected
EM, unless you manually call close on kem...
> 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)
