On Dec 12, 2012, at 6:39 PM, "Vergara, Jeaneth Aguilar" <[email protected]> wrote:
> Monotonic read consistency means if a process has seen a particular value for > the object, any subsequent accesses will never return any previous values. > (quoted from > http://www.allthingsdistributed.com/2007/12/eventually_consistent.html). Aside from the aforementioned bug [1], requesting reads with PR=quorum will achieve this. Let me rephrase the guarantee this gives you: Any actor A will always read values causally equal or greater than previous reads by the same actor. > > Yes, the cache is local to each actor. The actor can read something that it > did not write. When it tries to read that object again, it needs to ensure > that it either gives back the previously read version because it's more > current or return the new one (because it's the latest value). If the Riak > server returns an older value (maybe due to a partition failure and it gave > back an older value), then we can catch that scenario. > > If the last modified timestamp is consistent across all replicas, then maybe > we can just use that value instead of setting up our own vector clock. Can > you please confirm it's the same in all replicas (or it's the same value for > all consistent replicas)? What I mean is for A/B/C/D/E, assuming there's no > partition, they'll all have the same value of Dec. 12, 2012 2:20 PM once that > update is propagated to all replicas. The timestamp is tied to a particular 'version' of an object. The same timestamp will always be returned when any replica returns the same version. In all but some extreme cases (ie. spanner), timestamps are not suitable for guaranteeing causality though. > > From: Reid Draper [[email protected]] > Sent: Wednesday, December 12, 2012 2:45 PM > To: Vergara, Jeaneth Aguilar > Cc: [email protected]; Shah, Nikhil M > Subject: Re: Monotonic Read Consistency > > > On Dec 12, 2012, at 4:01 PM, "Vergara, Jeaneth Aguilar" > <[email protected]> wrote: > >> Thanks Reid, we have that implementation for Read Your Writes already. We'd >> like to implement Monotonic Read Consistency as well. For Monotonic Read >> Consistency, we were hoping to do Vector Clock comparison but we don't know >> how to convert the byte[] into different client's timestamps. > > Can you go into more explanation of exactly what you mean by 'Monotonic Read > Consistency'? > > Vectors clocks in Riak are meant to be opaque. It's not impossible to > use/decode them, but it's not trivial (particularly outside of Erlang). > We've not run into a use-case (afaik) where someone _needed_ to decode them. > >> >> Here's a work around we've thought of for now to implement Monotonic Read >> Consistency: >> >> 1. We'll just add another field in our object to track which client wrote it >> and a version number (so sort of implementing our own vector clock) >> 2. Then we'll just do last write wins (no siblings) >> 3. We'll cache our writes and reads > > where is this cache? is it local to each actor? If so, sounds like you've > just implemented read-your-writes > > >> 4. If we do a read and it has a vector clock less than what's in our cache, >> we'll use the one in our cache >> 5. If we do a read and it has a vector clock greater than what's in our >> cache, we'll update our cache and use that latest version >> >> If you know of a way how a client can interpret the vector clock returned by >> Riak API, then we don't have to implement our own poor man's vector clock. >> >> Also, what's the timestamp returned as part of the Riak API? Is that the >> timestamp when the response was created? Or is that the timestamp of the >> record inside each instance of Riak DB where that data came from -- is that >> timestamp consistent across all replicas? > > The last-modified timestamp should be when the write for that version of the > value was recorded. > > >> >> From: Reid Draper [[email protected]] >> Sent: Wednesday, December 12, 2012 11:21 AM >> To: Vergara, Jeaneth Aguilar >> Cc: [email protected] >> Subject: Re: Monotonic Read Consistency >> >> If your writes and reads are written with PR+PW > N (note PR/PW and not >> R/W), then you should get read-your-writes consistency. There is >> unfortunately a bug with PR/PW [1] that means this is not a 100% guarantee >> at the moment. I'm hoping for it to be fixed by Riak 1.4, if not earlier. I >> don't have JavaDoc handy, but setting PR and PW should be the same as >> setting any other per-request parameter. For an N value of 3 (the default), >> I'd likely recommend setting PR and PW to 2. You can get around the >> aforementioned bug by setting PR=PW=N, which will lower your availability, >> but gaurantee read-your-writes consistency. >> >> Note that read-your-writes is slightly different than just monotonic read >> consistency, but I'm guessing it's closer to what you had in mind. >> >> [1] https://github.com/basho/riak_kv/issues/388 >> >> Reid >> >> >> On Dec 5, 2012, at 11:13 PM, "Vergara, Jeaneth Aguilar" >> <[email protected]> wrote: >> >>> Hi there, >>> >>> We're trying to implement monotonic read consistency at the client side >>> using Riak's Java client. We're kind of stumped on how to do vector clock >>> comparison so we can ensure that we're always getting the latest version. >>> >>> Any tips would be appreciated. >>> >>> Thanks, >>> Jing >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
