[ 
https://issues.apache.org/jira/browse/OPENJPA-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032925#comment-14032925
 ] 

Kevin Sutter commented on OPENJPA-1193:
---------------------------------------

Yes, that was part of the discussion.  Unfortunately, we couldn't get consensus 
that the misplaced ! was the real problem.  And, my comment above was not 
stated correctly.  It's not a requirement to clean up the EMs when the 
transaction rollsback, but rather to rollback the transasction when there's an 
error.  This in turn would allow the clean up of the EMs.  Something like this 
worked for the user on the thread above:

if (em.getTransaction().isActive()){
                    em.getTransaction().rollback();
}

(I have edited my previous comment to be more consistent.)

> Memory leak when using FinalizingBrokerImpl
> -------------------------------------------
>
>                 Key: OPENJPA-1193
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1193
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.2.0, 1.2.1, 2.1.1, 2.2.0
>         Environment: All environments where the finalizing broker is used
>            Reporter: David Minor
>            Assignee: Donald Woods
>             Fix For: 1.3.0
>
>         Attachments: fix-finalizing-broker-memory-leak.patch
>
>
> When FinalizingBrokerImpl is used, AbstractBrokerFactory uses a set backed by 
> java's ConcurrentHashMap to keep track of brokers, rather than a weak 
> reference org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashSet 
> as it did previously. This can lead to a memory leak if the brokers are never 
> removed from the Set.
> The change was originally checked in by Patrick Linskey in revision 653000 
> with the comment "Improve concurrency by actively managing 
> AbstractBrokerFactory's broker set when using non-finalizing brokers. Credit 
> goes to Arunabh Hazarika for identifying the bottleneck and prototyping this 
> solution."
> Changing the _brokers Set back to a weak reference ConcurrentReferenceHashSet 
> fixes the memory leak.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to