Community
Participate
Working Groups
Build: I20050509-2010 If a PRE_CLOSE resource change listener tries to modify the workspace, they should get an exception explaining that the tree is locked. In some cases they do not get this exception, but instead get a different exception stating that the scheduling rule conflicts (see bug 94435).
PRE_CLOSE notification currently happens before acquiring any scheduling rule. Thus if another workspace operation runs in another thread during PRE_CLOSE notification, it will reset the "tree locked" flag when it finishes (POST_CHANGE notification at the end). After that, if a PRE_CLOSE listener tries to modify the workspace, the tree is no longer locked, so they get the scheduling rule error instead. One solution is to use a ThreadLocal for storing the tree locked state, to avoid it being corrupted by a concurrent operation in another thread. Another solution is to hold the workspace lock while performing PRE_CLOSE notification. This will prevent concurrent operations from happening in other threads. This might be the better solution since resource change listeners are likely not expecting to be called in multiple threads concurrently. This might be a bit risky for 3.1. Considering it has always been this way there is not a compelling risk of waiting until 3.2 to fix it properly.
*** Bug 104456 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
