[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] transaction freeze
|
Whew; a common mistake for us all do not worry about it.
We did not need featurecollection.close( iterator ) on trunk as we are making use of the featureIterator.close() as often as we can.
You can make use of feature iterator on 2.6 if you like.
Jody
On 27/08/2010, at 11:41 PM, andrea antonello wrote:
> Ok, this is exposing me but at least it will be educating others :)
>
> In some hidden piece of my code I wasn't closing an iterator on a
> featurecollection. ALWAYS REMEMBER TO CLOSE YOUR ITERATOR, else you
> see what might happen!!!! :)
>
> One quick question on this.
> Currently I close the iterator trhough:
>
> featurecollection.close(iterator)
>
> while I think I saw in geotools 2.7 that this is deprecated and you should use:
>
> iterator.close() directly? (which in 2.6 doesn't work).
>
> Andrea
>
>
>
>
>
> On Fri, Aug 27, 2010 at 3:04 PM, andrea antonello
> <andrea.antonello@xxxxxxxxx> wrote:
>> 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
>>>
>>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
