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

[Cèsar Ordiñana]

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