[
https://issues.apache.org/jira/browse/DBCP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philippe Mouawad updated DBCP-294:
----------------------------------
Attachment: Test.zip
Test case
> 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.
