[
https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600458#action_12600458
]
Kristian Waagan commented on DERBY-3401:
----------------------------------------
I had a look at ' d3401-statement_events.diff'. I think it looks good, but I
have one question.
Any reason why you allow null objects into the list of listeners in
ClientPooledConnection40 and ClientXAConnection40?
Can't you get an NPE when you iterate through the list of listeners and invoke
the callback method?
I ran the new test(s) successfully, but modifying it to add a null listener
causes failures.
+1 to commit if you plan to address the NPE elsewhere or in a followup 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-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.
