db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3401) Removing a ConnectionEventListener from a PooledConnection during its connectionClosed() callback causes other ConnectionEventListener callbacks to be missed
Date Wed, 28 May 2008 12:51:46 GMT

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


Mime
View raw message