commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (POOL-131) Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log errors about passivation/destroying
Date Wed, 11 Apr 2012 20:59:17 GMT


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
> ----------------------------------------------------------------------------------------------------------------
>                 Key: POOL-131
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message