db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5549) Questionable behaviour of PooledConnection after receiving an interrupt
Date Thu, 22 Dec 2011 01:19:30 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174553#comment-13174553
] 

Dag H. Wanvik commented on DERBY-5549:
--------------------------------------

The connection not being closed is a red herring. The exception you see here labeled "expected"
in the repro is really SQLSyntaxErrorException: there is a syntax error (superfluous right
parenthesis in the create table statement). Hence, the connection is still open.
                
> 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
>         Attachments: TestPooledConnection.java
>
>
> 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

        

Mime
View raw message