[
https://issues.apache.org/jira/browse/POOL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated POOL-131:
-----------------------------
Fix Version/s: (was: 1.5)
2.0
There is currently no logging in pool. Whether there should be (almost
certainly) and what form it should take are topics for future discussion.
Adding logging of any form is going to be have sufficient impact that it should
wait until 2.0
> 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.
-
You can reply to this email to add a comment to the issue online.
