commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe Mouawad (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DBCP-294) Memory leak in XA Implementation
Date Sun, 14 Jun 2009 15:04:07 GMT

    [ https://issues.apache.org/jira/browse/DBCP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718978#action_12718978
] 

Philippe Mouawad edited comment on DBCP-294 at 6/14/09 8:03 AM:
----------------------------------------------------------------

Please find attached a patch to TransactionRegistry.
The idea is to unregister connection instead of relying on WeakHashMap release.
Release will be done by PoolableManagedConnection#reallyClose()

Philippe Mouawad
http://www.ubik-ingenierie.com

      was (Author: pmouawad):
    Please find attached a patch to TransactionRegistry.
The idea is to unregister connection instead of relying on WeakHashMap release.
Release will be done by PoolableConnection#reallyClose()

Philippe Mouawad
http://www.ubik-ingenierie.com
  
> Memory leak in XA Implementation
> --------------------------------
>
>                 Key: DBCP-294
>                 URL: https://issues.apache.org/jira/browse/DBCP-294
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.3, 1.4, 2.0
>         Environment: JDK5, Oracle 10G
>            Reporter: Philippe Mouawad
>            Priority: Critical
>         Attachments: patch-TransactionRegistry.txt, PoolableManagedConnection.java, PoolableManagedConnectionFactory.java,
Test.zip
>
>
> Hello,
> We are been using Ofbiz with DBCP based implementation.
> Ofbiz uses a Head revision of DBCP (package org.apache.commons.dbcp.managed is the same
as current TRUNK) and geronimo-transaction-1.0.
> We are having recurrent OutOfMemory which occur on a 2 days basis.
> I analyzed the Heap Dump and I think have found the source of the problem:
> The Heap Dump shows a Retained Heap of 400Mo by org.apache.commons.dbcp.managed.TransactionRegistry#xaResources
field.
> After analyzing more deeply, the leak seems to come from what is stored in xaResources
through
> xaResources.put(connection, xaResource);
> Values inside weak Hash map  will never be removed since XAResource holds a STRONG reference
on key (connection) through:
> org.apache.commons.dbcp.managed.LocalXAConnectionFactory$LocalXAResource through:
> public LocalXAResource(Connection localTransaction) {
>             this.connection = localTransaction;
>         }
> Found in WeakHashMap javadoc:
> Implementation note: The value objects in a WeakHashMap are held by ordinary strong references.
>>>>>>>>>>>>>Thus care should be taken to ensure that
value objects do not strongly refer to their own keys <<<<<<<<, either
directly or indirectly, since that will prevent the keys from being discarded. Note that a
value object may refer indirectly to its key via the WeakHashMap itself; that is, a value
object may strongly refer to some other key object whose associated value object, in turn,
strongly refers to the key of the first value object. One way to deal with this is to wrap
values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)),
and then unwrapping upon each get. 
> Philippe Mouawad
> http://www.ubik-ingenierie.com

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message