[
https://issues.apache.org/jira/browse/OPENJPA-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295986#comment-14295986
]
brian yoder commented on OPENJPA-2566:
--------------------------------------
Thanks. Yes, the leak happens without using FetchPlan at all, so the leak has
to do with using the EM that is returned from the OpenJPAPersistence.cast(em)
call.
Assuming that the EM is somehow a new one would there be any issue doing
try,catch,finally with calling jpaEM.close() in the finally clause? Wondering
if the container (CMP) would have issues trying to commit etc. if I call close
in the finally before the method returns back to the CMP. Hopeing to find
workarround on this until a fix is available.
Also should I file separate bug on the OpenJPAQuery cast bug on Glassfish?
> 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)
