[
https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851386#action_12851386
]
Paul Benedict commented on DBCP-329:
------------------------------------
My employer does high-transaction processing -- about 2 million real-time
invocations a day -- and are also on a mainframe where they pay for processor
usage. They prohibit a validation query since it would cost 2 million more SQL
statements a day. In an emergency reboot, connections are left hanging and each
one throws an exception until the pool is re-cleared. It would be nice to see
an option where a stale connection (exception from isClose()?) refreshes the
entire pool.
I agree with Phi. There's no right answer except what is right for you. I think
we should support some configuration option where either (1) silent disposal
(2) throw exception and (3) refresh the pool.
> 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.
