[
https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851360#action_12851360
]
Phil Steitz commented on DBCP-329:
----------------------------------
James: good point, but the answer is "not exactly." The check on isClosed()
that I mentioned above happens *before* the connection is returned to the pool
(in the pool lifecycle, before passivate happens). What it comes down to is
do we want to let the client know (via an exception) as soon as we detect the
condition that one of the connections handled by the pool has been closed
externally. The reasonable alternative behavior be to "silently" dispose of
the connection wrapper and exit close normally. One reason to let the client
know about this is that DBCP in this case is not fulfilling any of its normal
"close" contract cleanup actions (rollbacks, etc.).
> SQLException: Already closed.
> -----------------------------
>
> Key: DBCP-329
> URL: https://issues.apache.org/jira/browse/DBCP-329
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.4
> Environment: MySQL
> Reporter: Hontvari Jozsef
>
> After upgrading to 1.4 I see such exceptions logged:
> java.sql.SQLException: Already closed.
> at
> org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
> at
> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
> ...
> This should never happen. According to the Connection.close() javadoc:
> "Calling the method close on a Connection object that is already closed is a
> no-op."
>
> Moreover, I am pretty sure that our code does not close the connection twice.
> But because the close() is called in a finally block, it is possible that
> this exception hides another exception. Unfortunately I cannot reproduce it,
> even though it occurs regularly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
