[
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.
