[
https://issues.apache.org/jira/browse/POOL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706323#action_12706323
]
Mauro Molinari commented on POOL-131:
-------------------------------------
Meanwhile, couldn't exceptions be propagated, maybe inside RuntimeExceptions?
In the use case I mentioned, I think it's very bad that exceptions are totally
lost, also because they're affecting the correct behaviour of the pool.
If it were just a logging issue, I would agree with you.
> 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.
