Community
Participate
Working Groups
Build Identifier: 3.6.0 - I20100527-1700 Within a product that builds on Eclipse and WTP the following scenario can cause the UI to block a user from completing an operation (until a different long-running operation completes), when I don't think it should happen. 1) Create a workspace with 2 different projects (project1 and project2) that contain a bunch of files (the contents don't really matter). 2) Create a server instance (using WTP tooling). 3) Publish project1 to that server. This operation may take a long period of time so WTP runs the publish action in a Job that has a scheduling rule of the server object + the projects published to the server (i.e project1). 4) Try to delete a file from project2 while the publish action is occurring. When step 4 executes you'll get the 'User Operation Waiting' dialog showing the blocked jobs and will be displayed until the publish operation in step 3 completes. I looked into why this was happening at it looks like the org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation#run() method acquires a workspace lock to perform the deletion request, which of course will block as I already have a lock on a project in the workspace. Is a workspace lock really necessary when trying to delete a single (or set) of files? If I was deleting a file in project1 (the one being published to the server) than I would understand the blocking job dialog; However, in this case I really should be able to delete a file that is not currently used by anything else. Reproducible: Always
> Must RefactoringWizardOpenOperation use a workspace lock? Unfortunately yes, mainly because we don't know what resources participants are going to touch and because the workspace does not allow to enlarge an initially taken rule later (this prevents deadlocks). *** This bug has been marked as a duplicate of bug 239404 ***
Is there a possibility that the code can be reworked so that participants can tell you ahead of time (before you do any locking) if they require a higher kind of lock and then apply multi-lock during the operation.
Everything is possible, but this comes with a high cost. Up to now, refactoring always ran with the workspace lock. If we relax that, many more issues can show up, so this would need quite some testing and review of the whole refactoring implementation to find loopholes (e.g. if you delete a file with a special encoding, you also get a change in a .settings/*.prefs file, so do we need a rule for that?). A further complication is that participants are only loaded lazily based on the selected element, so it is not easy to know about the right lock when we start the refactoring. And if we don't hold a large enough lock at the time the refactoring and the processors are initialized, there's a new opportunity for race conditions if the workspace is being modified concurrently. Troy/Angel: If you need this in a product, please file an IES request.
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. -- The automated Eclipse Genie.
