>>>>> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>>> In the case of multiple concurrent writes, you're bound to lose one
>>> of the two writes whichever mechanism is used.
>> I don't understand how the schemes being discussed are different
>> with respect to this point?
> They aren't.
> The only way that this issue can be prevented is if each module is
> treated as a single transaction. In practice, it shouldn't be that
> much of a problem; if two processes are trying to replace the same
> map with competing versions, that's really an organisational issue,
> not a technical issue.
Agreed.
[...]
>> From the discussion, I could conclude that the inventory scheme
>> doesn't necessary imply any better concurrency (other than by
>> allowing certain ways of lock-less access), nor does it prevent the
>> concurrency to be improved (by means of the OS locking.)
>> Still, I believe the inventory scheme to be more flexible and to
>> allow for both cleaner and extensible API, and a cleaner
>> implementation.
... And it eliminates certain problems with database replication
as well.
> The main disadvantage is it makes it harder for the user to analyse
> or modify the database manually (which is sometimes necessary).
The use of advisory locks seem to make manual modifications
harder as well. May I suggest g.replacefile and (or) g.editfile
to complement g.findfile, ensuring proper locking is done?
BTW, it would be nice to have a way to obtain a list of all the
files comprising the given raster or rasters.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
