Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321373

Summary:	[refactoring] Must RefactoringWizardOpenOperation use a workspace lock?
Product:	[Eclipse Project] JDT	Reporter:	Troy Bishop <tjbishop>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	arvera, deepakazad, markus.kell.r, remy.suen
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Troy Bishop

2010-07-30 12:04:09 EDT

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

Comment 1 Markus Keller

2010-08-09 04:56:17 EDT

> 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 ***

Comment 2 Angel Vera

2010-08-09 13:46:11 EDT

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.

Comment 3 Markus Keller

2010-08-10 11:57:45 EDT

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.

Comment 4 Eclipse Genie

2019-08-11 17:04:44 EDT

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.