[
https://issues.apache.org/jira/browse/DERBY-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597869#action_12597869
]
Trejkaz commented on DERBY-3675:
--------------------------------
Not in our own code, but the connection pool manager does remove the listener
like this:
private class PoolConnectionEventListener implements ConnectionEventListener {
public void connectionClosed (ConnectionEvent event) {
PooledConnection pconn = (PooledConnection) event.getSource();
pconn.removeConnectionEventListener(this);
recycleConnection(pconn);
}
public void connectionErrorOccurred (ConnectionEvent event) {
PooledConnection pconn = (PooledConnection) event.getSource();
pconn.removeConnectionEventListener (this);
disposeConnection(pconn);
}
}
And then it reattaches it when it gives the connection out again.
> ConcurrentModificationException on closing pooled connection
> ------------------------------------------------------------
>
> Key: DERBY-3675
> URL: https://issues.apache.org/jira/browse/DERBY-3675
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.4.1.3
> Reporter: Trejkaz
>
> I'm seeing the following exception from calling close() on a connection
> returned from a CollectionPoolDataSource.
> java.util.ConcurrentModificationException
> at
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
> org.apache.derby.client.ClientPooledConnection.recycleConnection(ClientPooledConnection.java:343)
> at
> org.apache.derby.client.am.LogicalConnection.close(LogicalConnection.java:83)
> The only particularly unique thing about the area of the code where we're
> doing this is that we're closing it immediately after opening it, as an
> initial check to make sure it can connect.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
