Ivan Shmakov wrote: > > To make concurrent access work, updating a map would need to be an > > atomic operation, so that any module which reads the map sees either > > the "before" version or the "after" version, and never sees an > > "in-progress" version. > > And that's simple. It's only the current layout of the GRASS > database directory that makes it hard. The new layout may be > like the following:
[snip] A simpler (and less radical) solution is to simply all elements of a map in a common directory. Then, you replace the directory as a whole rather than individual files. ISTR that this is already planned for the future. The downside is that you can't atomically replace a directory in the same way that you can a file. You have to rename the destination first, which leaves a small window when the map doesn't exist. But a transient state with no map is still better than the current situation of a transient state with an inconsistent map. Full transaction support would be nice, but I don't know if it's worth the substantial effort involved in implementing it. In any case, all of these mechanisms would require substantial changes to a large number of modules. And there's still the issue of vector maps, which are often updated in-place. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
