Cassandra does this interestingly enough and is more baked than the suggestions posed thus far. As it is an eventual consistency database it needs to pull the freshest ID of a record, similar to a file. That ID is based on a timestamp and a server hash (potentially more things). It might be worth looking in to if this is not fully baked. I have not seen the issues Stephen has been mentioning though. I've been running in production on 3.3 without incident. On Jan 8, 2013, at 8:07 AM, Stephan von Krawczynski <skraw at ithnet.com> wrote: > On Tue, 08 Jan 2013 07:54:05 -0500 > Jeff Darcy <jdarcy at redhat.com> wrote: > >> On 1/8/13 7:11 AM, Stephan von Krawczynski wrote: >>> Nobody besides you is talking about timestamps. I would simply choose an >>> increasing stamp, increased by every write-touch of the file. >>> In a trivial comparison this assures you choose the latest copy of the file. >>> There is really no time needed at all, and therefore no time synchronisation >>> issues. >> >> When you dismiss change logs and then say "latest" without elaboration then >> it's not unreasonable to assume you mean timestamps. Perhaps you should try to >> write more clearly. >> >> Versions are certainly an improvement over timestamps, but they're not as >> simple as you say either - and I've actually used versioning in a functional >> replication translator[1] so I'm not just idly speculating about work other >> people might do. If two replicas are both at (integer) version X but are >> partitioned from one another, then writes to both could result in two copies >> each with version X+1 but with different data. > > This can only happen in a broken versioning. Obviously one would take (very > rough explanation) at least a two-shot concept. You increase the version by > one when starting the file modification process and again by one when the > process is completed without error. > You end up knowing that version nr 1,3,5,... are intermediate/incomplete > versions and 2,4,6,... are files with completed operations. > Now you can tell at any time throughout any stat comparison which file is > truely actual and which one is in intermediate state. If you want that you can > even await the completion of an ongoing modification before returning some > result to your requesting app. Yes, this would result in immanent locking. > > -- > Regards, > Stephan > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users
