[
https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3401:
--------------------------------------
Attachment: d3401-connection_events.stat
d3401-connection_events.diff
Attaching a patch which fixes the problem with the ConnectionEventListeners,
enables the test case for removing a listener and adds a test case for adding a
listener.
The fix makes the PC update a variable each time it starts iterating over the
list of listeners and each time it has finished iterating. That way,
(add/remove)ConnectionEventListener knows if the list is currently being
iterated over. If it is being iterated over, the list is cloned and the
add/remove operation is performed on the clone. That way, the iterator is not
affected and continues to work just as if no listener has been added or removed.
The logic is somewhat more complex than the code for the statement event
listeners, as we don't have CopyOnWriteArrayList available in Java 1.4.
However, it is less costly, as it only copies the list in the cases where
modifying the list directly would have caused problems (CopyOnWriteArrayList
always copies the list when it's modified).
All the regression tests passed with this patch.
> Removing a ConnectionEventListener from a PooledConnection during its
> connectionClosed() callback causes other ConnectionEventListener callbacks to
> be missed
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3401
> URL: https://issues.apache.org/jira/browse/DERBY-3401
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.4.1.3
> Reporter: Daniel John Debrunner
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d3401-connection_events.diff,
> d3401-connection_events.stat, d3401-statement_events.diff,
> d3401-statement_events.stat
>
>
> A ConnectionEventListener should be able to remove itself as a listener
> during a callback without affecting any other callbacks.
> DataSourceTest.subtestPooledRemoveListenerOnClose() tests the scenario but
> calls to it will be commented out in the fixture testPooledReuseOnClose()
> (using this bug number).
> Issue is that such a remove will modify the eventListener Vector in
> EmbedPooledConnection while it is being enumerated over.
> An idea for a fix would be to first change the Vector over to a new-style
> collection, such as an implementation of List, then work off a copy of the
> collection when calling the callbacks. I don't think eventListener needs to
> be a synchronized collection, its access should be already synchronized on
> EmbedPooledConnection.
> I imagine that a similar issue exists for adding a new callback during
> callback processing, fixing this bug would fix that issue as well though no
> tests have been written for the add case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
