[
https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174597#comment-13174597
]
Trejkaz commented on DERBY-5549:
--------------------------------
Ah, quite right. I'll have to come up with a fix for the test to show the
problem. It's occurring for real in our real app, but condensing it down to a
small test is rather challenging.
Problem is it's also 2 hours from the end of my last work day for the year... ;)
> Questionable behaviour of PooledConnection after receiving an interrupt
> -----------------------------------------------------------------------
>
> Key: DERBY-5549
> URL: https://issues.apache.org/jira/browse/DERBY-5549
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.2.2
> Environment: Windows 7 64-bit
> Reporter: Trejkaz
>
> If using pooled connections and a connection is interrupted while doing some
> work, the underlying connection is closed, but none of this information is
> relayed to the pooled connection itself.
> As a result, attempting to use the pooled connection after interrupting a
> *previous* caller caused the connection to be closed results in a "No current
> connection." exception every time getConnection() is called on it.
> The exception handed to callers is a proxy of sorts and isClosed() on this
> connection returns false, which appears to be in contradiction with the
> documentation about how interrupts are handled. Additionally, even though a
> connection error occurs, the appropriate ConnectionEventListener method,
> connectionErrorOccurred, is not called. So there appears to be no way to
> know if this has occurred from the outside, short of looking for the
> interrupt flag itself (which makes the assumption that it hasn't been cleared
> since the connection was closed.)
>
> The workaround in our particular case is to check for the flag, because it
> happens to still be set when we get to the listener (at least for now.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
