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 "Alan Burlison (JIRA)" <ji...@apache.org> on 2009/05/12 11:09:45 UTC
[jira] Created: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
-----------------------------------------------------------------------------------
Key: DERBY-4225
URL: https://issues.apache.org/jira/browse/DERBY-4225
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.5.1.1
Environment: Solaris
Reporter: Alan Burlison
Priority: Blocker
I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
----------
class PoolConnectionEventListener implements ConnectionEventListener {
...
}
:
EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
:
connListener = new PoolConnectionEventListener();
:
PooledConnection conn = pconn.getConnection();
conn.addConnectionEventListener(connListener);
----------
This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JDNI context.
I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4225:
--------------------------------------
Attachment: ConnectionPoolTest.java
I didn't see this problem when I wrote a small program to test it (see attached ConnectionPoolTest.java). Is there a way we could reproduce it?
One possibility is that you're seeing the changes introduced by DERBY-3319, documented in this release note: http://db.apache.org/derby/releases/release-10.5.1.1.cgi#Note+for+DERBY-3319
If that's the case, the call to close() fails because there are uncommitted operations and the connection remains open, so the connection event listener won't be called. The way to fix it is to make sure the connection is committed or rolled back before close() is called.
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
> Attachments: ConnectionPoolTest.java
>
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Alan Burlison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Burlison closed DERBY-4225.
--------------------------------
Resolution: Invalid
As Knut Anders Hatlen suggested, this issue was caused by the change in behaviour caused by the fix for DERBY-3319. After carefully reviewing the application, several places were identified where the exception thrown by closing a connection without a commit were being ignored. After fixing them, the problem no longer occurs. Many thanks to Knut for identifying the problem.
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
> Attachments: ConnectionPoolTest.java
>
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708555#action_12708555 ]
Knut Anders Hatlen commented on DERBY-4225:
-------------------------------------------
Right, there should be an exception thrown by close() if DERBY-3319 is the issue. I could take a look at the code if you post the instructions on how to get it.
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
> Attachments: ConnectionPoolTest.java
>
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Alan Burlison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Burlison updated DERBY-4225:
---------------------------------
Description:
I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
----------
class PoolConnectionEventListener implements ConnectionEventListener {
...
}
:
EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
:
connListener = new PoolConnectionEventListener();
:
PooledConnection conn = pconn.getConnection();
conn.addConnectionEventListener(connListener);
----------
This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
was:
I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
----------
class PoolConnectionEventListener implements ConnectionEventListener {
...
}
:
EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
:
connListener = new PoolConnectionEventListener();
:
PooledConnection conn = pconn.getConnection();
conn.addConnectionEventListener(connListener);
----------
This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JDNI context.
I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Alan Burlison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708558#action_12708558 ]
Alan Burlison commented on DERBY-4225:
--------------------------------------
Thanks for the offer, but before I impose on your time I need to do some more digging in the application. I've found one place where the exception thrown by a close without a prior commit or rollback is ignored, there may be others. If I fix all those and I still get the problem, I'll update the bug. Thanks!
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
> Attachments: ConnectionPoolTest.java
>
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4225) EmbeddedConnectionPoolDataSource40
never calls the ConnectionEventListener calbacks
Posted by "Alan Burlison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708457#action_12708457 ]
Alan Burlison commented on DERBY-4225:
--------------------------------------
Hmm, that could be related but I'm not seeing any exceptions thrown by the close calls. According to DERBY-3319 & the release notes, if I close a connection with uncommitted changes I should get an exception with a SQLState 25001, correct? I'm not seeing any exceptions, the close seems to complete but the underlying event listener calls never get made.
I'll carry on digging, I can provide instructions on how to pull the app in question from our repo if required, the only prerequisite is a copy of NetBeans, when the NB project is opened and run the app creates and deploys a new DB.
> EmbeddedConnectionPoolDataSource40 never calls the ConnectionEventListener calbacks
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4225
> URL: https://issues.apache.org/jira/browse/DERBY-4225
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.1.1
> Environment: Solaris
> Reporter: Alan Burlison
> Priority: Blocker
> Attachments: ConnectionPoolTest.java
>
>
> I'm using EmbeddedConnectionPoolDataSource40 to implement a simple connection pool. A skeleton of the code looks like this:
> ----------
> class PoolConnectionEventListener implements ConnectionEventListener {
> ...
> }
> :
> EmbeddedConnectionPoolDataSource40 source = new EmbeddedConnectionPoolDataSource40();
> :
> connListener = new PoolConnectionEventListener();
> :
> PooledConnection conn = pconn.getConnection();
> conn.addConnectionEventListener(connListener);
> ----------
> This is so I can catch the connectionClosed and connectionErrorOccurred events and recycle the connections. In Derby 10.4.2.1 this all works fine, in 10.5.1.1 it doesn't work at all - the callbacks never get made. This makes 10.5.1.1 unusable in anything that uses connection pooling, such as a JNDI context.
> I haven't checked ClientConnectionPoolDataSource40, it may have the same problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.