You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2008/02/08 21:27:08 UTC
[jira] Created: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
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.0.0
Reporter: Daniel John Debrunner
Priority: Minor
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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600126#action_12600126 ]
Knut Anders Hatlen commented on DERBY-3401:
-------------------------------------------
I agree that copying the collection sounds like a reasonable approach. Strictly speaking, we only need a copy if there are at least two listeners in the list, but it is perhaps not worth the extra complexity to avoid copying 1-element lists. I'll try it and see how complex it gets.
Alternatively, we could have a copy-on-write scheme so that we only pay the extra price if we actually modify the list of listeners (this assumes that the listeners are triggered more frequently than they are modified). For the statement event listeners, we could get this more or less for free with java.util.concurrent.CopyOnWriteArrayList (new in Java 1.5) since that code is compiled with the 1.6 compiler.
> 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
>
> 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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3401:
--------------------------------------
Derby Info: [Patch Available]
> 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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3401:
--------------------------------------
Derby Info: [Patch Available]
> 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.
[jira] Commented: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602682#action_12602682 ]
Kristian Waagan commented on DERBY-3401:
----------------------------------------
I looked at the patch 'd3401-connection_events.diff' and it looks good to me.
suites.All (Sun JDK 1.5) and derbyall (Sun JDK 1.6) passed without failures.
+1 to commit
> 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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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-statement_events.stat
d3401-statement_events.diff
Here's a test and a fix for the statement event listeners. In the current trunk, adding or removing listeners from a listener causes ConcurrentModificationException (both client and embedded). Since this was JDBC 4.0 code, I went for the simple solution and just replaced Vector/ArrayList with CopyOnWriteArrayList and removed the synchronization.
All the regression tests passed.
> 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.
[jira] Commented: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598325#action_12598325 ]
Knut Anders Hatlen commented on DERBY-3401:
-------------------------------------------
I think this is also a problem for the statement event listeners (JDBC 4.0 feature).
> 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
> Priority: Minor
>
> 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.
[jira] Resolved: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-3401.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.4.1.4
Merged to 10.4 and committed revision 664655.
> 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
> Fix For: 10.4.1.4, 10.5.0.0
>
> 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.
[jira] Commented: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3401:
--------------------------------------
Derby Info: (was: [Patch Available])
Committed d3401-statement_events.diff with revision 660959.
> 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.
[jira] Updated: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3401:
--------------------------------------
Derby Info: (was: [Patch Available])
Fix Version/s: 10.5.0.0
Thanks for reviewing the patch, Kristian.
Committed revision 663641.
I'll probably merge it to 10.4 in a couple of days, so I'm leaving the issue open for now.
> 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
> Fix For: 10.5.0.0
>
> 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.
[jira] Assigned: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reassigned DERBY-3401:
-----------------------------------------
Assignee: Knut Anders Hatlen
> 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
>
> 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.
[jira] Commented: (DERBY-3401) Removing a ConnectionEventListener
from a PooledConnection during its connectionClosed() callback causes other
ConnectionEventListener callbacks to be missed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600480#action_12600480 ]
Knut Anders Hatlen commented on DERBY-3401:
-------------------------------------------
Thanks for looking at the patch Kristian. Since the different handling of null in client versus embedded is an existing issue, I filed a new bug (DERBY-3695) that I plan to address separately. You're quite right that it causes a NullPointerException on the client.
> 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.