Re: [udig-devel] transaction freeze

[andrea antonello <andrea.antonello@xxxxxxxxx>]

I am still on it.
Checking with lsof (on linux) when a file is in use. Still in the
middle of it, but did you know that the catalog (has to be it) holds a
grip on the prj files? I am wondering if it is a non closed Reader.

Will report if I find something.

Anyways I am quite sure I am doing something wrong, perhaps wrong way
to send edit commands.

Andrea

On Fri, Aug 27, 2010 at 2:56 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
> So the trick is ... who else has the write lock?  But good you hunted it down ...
> Jody
>
> On 27/08/2010, at 10:45 PM, andrea antonello wrote:
>
>> I debugged until I wandered through sun classes :)
>>
>> The lock is in:
>> ShpFiles.acquireWrite(ShpFileType, FileWriter) line: 508
>>
>> It blocks inside
>> readWriteLock.writeLock().lock();
>>
>> Inside:
>> java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock
>>
>> in the lock method
>>
>>        public void lock() {
>>            sync.acquire(1);
>>        }
>>
>> I loose it on aquire(1).
>> No way to recover.
>>
>> Andrea
>>
>>
>>
>> On Fri, Aug 27, 2010 at 2:38 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
>>> Bleck; that sounds like a deadlock. You should be able to "pause" in the debugger and see what threads are waiting; I am not the best at untangling such things :-(
>>>
>>> The commit dialog should be a two phase thing; the first command pops up the dialog; and then the dialog should issue a command that does all the work in the background (can you start by stepping through this process with the debugger and watching when it gets stuck?).
>>>
>>> Aside: If we really get stuck and cannot untangle our deadlock we could simplify the problem (prevent user interaction during commit by using a modal commit dialog with the confirmation starting a progress bar...).
>>>
>>> Jody
>>>
>>> On 27/08/2010, at 9:55 PM, andrea antonello wrote:
>>>
>>>> I have a problem with a transaction triggered from the form editor I
>>>> am writing for shapefiles.
>>>>
>>>> What happens is that:
>>>> - if I modify a value in the usual feature table and then commit,
>>>> everything works as it should
>>>> - if I modify with the form view, and the substitute and write the
>>>> modified feature through:
>>>>
>>>>        CompositeCommand compComm = new CompositeCommand();
>>>>        compComm.getCommands().add(EditCommandFactory.getInstance().createSetEditFeatureCommand(editedFeature));
>>>>        compComm.getCommands().add(EditCommandFactory.getInstance().createWriteEditFeatureCommand());
>>>>        context.getMap().sendCommandSync(compComm);
>>>>
>>>> Then, as soon as I push the commit button, the commit dialog opens and
>>>> stays there forever. Gui is frozen and committ hangs somewhere. I am
>>>> debugging through it and it seems to be in a nirvana inside the
>>>> DefaultTransaction class.
>>>>
>>>> Anyone any idea about how to solve that or why it is happening?
>>>>
>>>> Ciao
>>>> Andrea
>>>> _______________________________________________
>>>> User-friendly Desktop Internet GIS (uDig)
>>>> http://udig.refractions.net
>>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>>> _______________________________________________
>>> User-friendly Desktop Internet GIS (uDig)
>>> http://udig.refractions.net
>>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>