[
https://issues.apache.org/jira/browse/OPENJPA-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295163#comment-14295163
]
Rick Curtis commented on OPENJPA-2566:
--------------------------------------
> 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.
No, that is not the case.
Please try two things for me:
1.) Do the cast without using the FetchPlan. See if the leak goes away, if so
that tells me where to look.
2.) (Optional, but it would be very nice) Instrument the OpenJPA EntityManager
and see if .close() is ever being called by Glassfish.
I still suspect that the problem is that Glassfish is creating EntityManagers,
but never closing them. Prior to you using FetchPlans they were avoiding a leak
by relying on gc to clean things up. I don't have time to dig into the code
right now, but if there is some sort of a FetchPlan tracker at the EMF level
that could cause what we are seeing.
> 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)
