[
https://issues.apache.org/jira/browse/OPENJPA-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295986#comment-14295986
]
brian yoder edited comment on OPENJPA-2566 at 1/28/15 10:49 PM:
----------------------------------------------------------------
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. Also I noticed that the EM returned from the cast call doesn't behave
the same - that is my em is supposed to be
TransactionAttributeType.NOT_SUPPORTED, such that lazy fields would return null
after the initial entity is retreived. But when using the em from the cast it
seems to be able to load lazy fields after the initial em.find is called, which
doesn't match the em passed into the cast.
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?
was (Author: byoder):
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)
