[Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment

Thu Jan 21 00:46:55 CET 2010

Ben and Cesar,

I understand what you are saying but the program should be stable and 
robust.

Most people using the system as a desktop machine, say a small company 
that might have 1-2 computers, will be pointing there copy of gvSIG at 
the same data. This increases the potential for file conflicts 
dramatically and it would only be a matter of time before a file would 
become corrupt.

I believe that although there are solutions out there where data can be 
stored in databases that are designed to support this type of activity. 
Most small companies would not go through the process of consolidating 
their data. Also if they are like my company, most of my data is 
transient project based information. Large central databases are good at 
storing reference data but lets face it most of this stuff never gets 
edited. The small project based shapefiles are the most likely candidate 
for corruption. Multiple users adjusting geometries, attribute data, etc.

I really think it essential that file locking is implemented at the 
system level as well. If a user can not achieve an exclusive lock of a 
file a big warning message should appear that gives them an option to 
proceed but warns them of the consequences. It is standard practice in 
computing that if you open and edit a file then it will not result in 
damage to your data -- the software developers should program for these 
scenarios.

So in summary...

(1) the development of file management routines in gvSIG 2.0 will avoid 
crashes when editing one instance of a shapefile that is also shown/used 
elsewhere in a view/another view/etc. This is great and I fully support 
this.
(2) It is imperative that gvSIG should achieve exclusive access to a 
file at the system level when editing this file to avoid two people 
trying the edit the same file at the same time. The lock only needs to 
be at the file level. Record locking is not required. Since gvSIG will 
be able to detect a locked file when another user requests exclusive 
access to a file for editing, the system should (a) present a dialog 
that tells them someone else is using the file, (b) maybe allow them to 
bypass this restriction if they want, and (c) suggest that they 
investigate the use of other GIS data storage solutions like PostGIS, 
etc... especially if they have multiple users manipulating different 
parts of the same file. A situation, I might add, is unusual for gvSIG 
to be doing straight out of the box.

Cheers Simon

Simon Cropper
Botanicus Australia Pty Ltd
PO Box 160, Sunshine, Victoria 3020.
P: 9311 5822. M: 041 830 3437.
mailto: scropper at botanicusaustralia.com.au 
<mailto:scropper at botanicusaustralia.com.au>
web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>

On 21/01/2010 1:37 AM, Cèsar Ordiñana wrote:
> Hi Ben,
>
> I agree with you, a database is the way to go for that scenario.
>
> Just in case someone faces up with that problem, and wants to develop
> the file level locking support, I think it would be more feasible now,
> so don't hesitate to ask for guidelines.
>
> Regards,
>
> Benjamin Ducke escribió:
>    
>> Hi Cesar,
>>
>> that sounds excellent. Regarding file level locking,
>> I think you should not bother with it too much.
>> If people need multi-user access to geodata, they
>> should use a PostGIS databases and leave it to the
>> DBMS to handle conflicts -- it's designed to do that.
>> File system locking will never work that well.
>>
>> Cheers,
>>
>> Ben
>>
>> ----- Original Message -----
>> From: "Cèsar Ordiñana"<cordin at disid.com>
>> To: "Users and Developers mailing list"<gvsig_internacional at listserv.gva.es>
>> Sent: Wednesday, January 20, 2010 2:22:16 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
>> Subject: Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in	production environment
>>
>> Hi Simon,
>>
>> First of all, thanks for all your feedback, suggestions and errors
>> reported.
>>
>> I'm deeply involved in the development of the gvSIG 2.0, so I would like
>> to explain what is being done in relation to your points 6 and 8.
>>
>> One of the main changes in gvSIG 2.0 is a complete design and
>> implementation of the data access library. Knowing the problems of
>> previous versions, like the ones you have highlighted, we added resource
>> management to the library implementation.
>>
>> This way, if the user opens many layers in the same or different views
>> from the same file, or even many table documents, we know they share the
>> same file. The resource management service also locks write access to a
>> resource, so two different layers (in the same gvSIG instance) can't
>> write a file at the same time, but one after the other.
>>
>> So now we have the basic tools to be able to solve some of those
>> problems, but still have to do some work to translate that knowledge to
>> the application level. Things like:
>>
>> - If you finish editing a layer, refresh other layers from the same file.
>> - Warn the user that he's trying to edit a layer which is being edited
>> in another view.
>> - ...
>>
>> I'm not sure how much development effort we will be able to spend in
>> this problem, but I think in gvSIG 2.0 we will be able to handle those
>> cases more gracefully, at least for the most regular ones.
>>
>> All of this for the single gvSIG instance with many layers/views of the
>> same file scenario. For the scenario of many gvSIG instances or other
>> applications opening the same file, we could use file locking at the
>> system level. But I hope this to be a more unusual case, as I don't
>> think we will be able to work on it for the gvSIG 2.0 release.
>>
>> Regards,
>>
>>
>>      
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>    