[
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: So I am clear, the Glassfish team owns the EM.getDeligate() logic,
correct? So there is a bug there wereby new EM's are created (when I call the
OpenJPAPersistence.cast(em) method it's just envoking the Glassfish library for
emWrapper.getDeligate()...), that are detached, thus creating this issue? And
since the getDeligate is detached, and doesn't match the transaction type of
the em passed in it is your opinion the bug lies with Glassfish, correct?)
> 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)
