You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Trejkaz (Created) (JIRA)" <ji...@apache.org> on 2011/12/21 01:09:31 UTC
[jira] [Created] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
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
[jira] [Updated] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Mamta A. Satoor (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-5549:
-----------------------------------
Labels: derby_triage10_9 (was: )
> 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
> Labels: derby_triage10_9
> 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
[jira] [Updated] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Trejkaz (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trejkaz updated DERBY-5549:
---------------------------
Attachment: TestPooledConnection.java
Updated test correcting that bug (and asserting the specific error coming back just to make sure it's the one we expect.)
Now connection.isClosed() is in fact returning true, but the error handler still isn't being called.
> 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
[jira] [Updated] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Trejkaz (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trejkaz updated DERBY-5549:
---------------------------
Attachment: TestPooledConnection.java
Attaching my reproduction.
> 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
[jira] [Commented] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175665#comment-13175665 ]
Dag H. Wanvik commented on DERBY-5549:
--------------------------------------
Yes, I am seeing this. Looks wrong.
> 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
[jira] [Commented] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Trejkaz (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trejkaz updated DERBY-5549:
---------------------------
Attachment: (was: TestPooledConnection.java)
> 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
[jira] [Commented] (DERBY-5549) Questionable behaviour of
PooledConnection after receiving an interrupt
Posted by "Trejkaz (Commented) (JIRA)" <ji...@apache.org>.
[ 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