Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 11 Apr 2012 20:59:17 +0000 (UTC)
From: "Mark Thomas (Resolved) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <811689884.14357.1334177957125.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (POOL-131) Make
 org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log
 errors about passivation/destroying
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/POOL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Thomas resolved POOL-131.
------------------------------

    Resolution: Fixed

This has been fixed for POOL2 via exposing the swallowed exceptions via a getter (accessible via JMX) and JMX notifications.
                
> Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log errors about passivation/destroying
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: POOL-131
>                 URL: https://issues.apache.org/jira/browse/POOL-131
>             Project: Commons Pool
>          Issue Type: Improvement
>    Affects Versions: 1.4
>         Environment: Spring Framework JTA transaction Manager + jBossTS + DBCP
>            Reporter: Mauro Molinari
>             Fix For: 2.0
>
>
> In our environment it happens the following. Suppose our code has a bug and does not release a connection previously obtained from DBCP. 
> Suppose a JTA transaction is in progress when this happens.
> When trying to commit this transaction, Spring has a guard that realizes that the owner of that transaction is in some way "dead", so it tries to close the connection before committing (I think this is a problem, however, let's go on). Closing the connection makes DBCP/Pool call returnObject on the GenericObjectPool, then addObjectToPool and, at last, passivateObject. As the connection is neither in auto-commit mode nor read-only, passivateObject issues a rollback on the connection but then jBossTS throws a SQLException saying that it is not allowed to issue a rollback on an underlying connection while a higher level JTA transaction is in progress. This exception is caught by returnObject and it is completely lost, because returnObject does not log it, nor it forwards it upward.
> The final result is that:
> - the connection is not given back to the Pool, because of the exception
> - however, the physical underlying connection to the DBMS remains open
> => we have a connection leak, without any proof of it (no exceptions are logged in any way)
> To get to these results I had to carefully debug my code. It would have been very easier if Pool logged exceptions thrown during passivation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira