Created attachment 51612 [details]
Thread dump

This is what I think is happening
1) When the user clicks on a Bpel file usage on the left hand side window, the XML refactoring code does the preview
using the following algorithm
     Start transaction on model
     o.n.m.bpel.refactoring.Renamer.doRefactoring( for the selected Bpel file only)
     Rollback transaction on the model 

2) Then when the user clicks on do refactoring, the XML refactoring code first tries to:
      rename the refactoring target file, 
      refresh the catalog model and, 
      then refactor the usages

3) When the code tried to refresh the catalog model by looking at each usage, it gets stuck trying to acquire a readLock
for the file that was previewed in step (1)

If you look at the thread dump, thats where the code is waiting for a readLock

I am going to request Vladimir to look into Bpel code and see why Renamer.doRefactoring() isn't releasing the readLock
when its done

Assigning to Vladimir so he can investigate further.

fixed in trunk and sierra:

Checking in BpelModelImpl.java;
/cvs/enterprise/bpel/bpelapi/src/org/netbeans/modules/bpel/model/impl/BpelModelImpl.java,v  <--  BpelModelImpl.java
new revision: 1.6.10.3; previous revision: 1.6.10.2

Checking in BpelModelImpl.java;
/cvs/enterprise/bpel/bpelapi/src/org/netbeans/modules/bpel/model/impl/BpelModelImpl.java,v  <--  BpelModelImpl.java
new revision: 1.8; previous revision: 1.7

Summary:
BpelModel must override rollbackTransaction() and invoke writeUnlock() at the end of rollback.

rollbackTransaction() should be more investigated

I've fixed deadlock:

xml refactoring framework calls:

bpelModel.startTransaction();
// changes
bpelModel.rollbackTransaction();

In BpelModelImpl startTransaction sets read/write locks
and invokes super.startTransaction(), but rollbackTransaction
was not overrided in bpel model (when bpel model was
implemented there was no rollbackTransaction method).
So, rollbackTransaction didn't unset read/write locks.

I have added this method in BpelModelImpl class.
It was implemented just as start/stopTransaction:
invokes super method and set/unset read/write locks.

But it looks like rollbackTransaction in AbstractModel
doesn't wrok properly: repeat the steps, you can
see in diff view that old and new files are the same.

Could you please, look at super rollbackTransaction?
It seems that super rollbackTransaction must undo
changes in bpel model but it doesn't happen.

I am not sure why the rollback is not happening. Before Vladimir's changes to BpelModelImpl, the
AbstractModel.rollbackTransaction() was rolling back the bpel model changes. The new method,
BpelModelImpl.rollbackTransaction(), does nothing but delegates the rollback to AbstrackModel.rollbackTransaction() but
now rollback doesnt happen and we have unsaved changes in the Bpel file after preview. Not sure what's happening. I have
verified that AbstractModel.rollbackTransaction() is getting executed with Vladimir's changes.

Vladimir, Nam, any ideas?

I've investigated AbstractModel and BPELModelImpl.
It seems that bpel model must rollback changes self:
to call own undo support.

 See changes:

diff -r1.8 BpelModelImpl.java
498c498
<             super.rollbackTransaction();
---
>           myUndoSupport.abortUpdate();
807a808,813
>         }
> 
>         protected void abortUpdate() {
>             ModelUndoableEdit mue = (ModelUndoableEdit) compoundEdit;
>             mue.justUndo();
>             super.compoundEdit = createCompoundEdit();

Fix Verified.

Product Version: NetBeans IDE Dev (Build 200710290000)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Linux version 2.6.22-14-generic running on i386; UTF-8; en_US (nb)