Thanks for sending this explanation, Vitaly! This helps for sure. Thank you all, guys!
-Qiang On Sun, Mar 6, 2016 at 3:24 AM, Vitaly E <13vitam...@gmail.com> wrote: > Hi Qiang, > > You mentioned that my suggestion to synchronize the clocks of your Riak > nodes had solved the problem. Let me explain why -- it may clear things up > for you. > > Riak uses vector clocks / version vectors > <http://docs.basho.com/riak/latest/theory/concepts/context/#Vector-Clocks> > to keep track of the sequence of updates to a particular key. These are > "logical clocks" as opposed to physical clocks that usually can't be relied > upon in a distributed system like Riak. Fetching the vector clock of a key > and passing it back on write (along with a new value), helps Riak decide > which modification is the "latest" one. Keep in mind that "concurrent > modification" does not necessary means simultaneous, but can happen due to > a network partition, for example. > > Normally, when a concurrent update is detected (based on vector clocks), > Riak returns siblings and lets a client decide which version should be > used. Since you're running with allow_mult = false, you've actually told > Riak to resolve conflicts for you. In this case Riak still uses vector > clocks when possible, and then time-stamps if there's still a conflict. > Obviously, if you don't pass vector clocks, only time-stamps will be used. > Moreover, without vector clocks any update is considered concurrent, Riak > just doesn't expose it with allow_mult = false (remember, you opted for > automatic conflict resolution?). > > Keep in mind that a time-stamp is assigned by the first Riak node a > request hits. The node then forwards the request based on the key this > request is trying to write > <http://docs.basho.com/riak/latest/theory/concepts/Clusters/>. > > Now, imagine that a write to a key passes through node X, and within 30 > sec another update to the same key passes through node Y, which is 2 min > behind node X. Since time-stamps are being used to resolve conflicts, the > second update will be considered older than the first one, and eventually > discarded. > > So, if this kind of conflict resolution is good enough for you, make sure > your Riak's clocks are in sync (NTP?). I would also suggest to pass vector > clocks anyway. > > Hope this helps. Everyone is welcome to correct/clarify. > > Vitaly > > > On Mar 5, 2016 11:07 PM, "Qiang Cao" <caoqiang...@gmail.com> wrote: > >> Thanks, Russell. I'm just curious. My application handles that. Maybe >> that's just because of the vclock. >> >> -Qiang >> >> On Sat, Mar 5, 2016 at 2:09 PM, Russell Brown <russell.br...@me.com> >> wrote: >> >>> And you pass the vclock back after a GET with the next POST? Unless we >>> get a look at the vclocks then it's hard to say why or where you have >>> concurrency. But since concurrency is ultimately unavoidable using riak, >>> why the concern? Can your application/data model handle it is the main >>> question? >>> >>> >>> On 5 Mar 2016, at 19:04, Qiang Cao <caoqiang...@gmail.com> wrote: >>> >>> Thanks, Russell! I do a GET immediately after a POST is done. I use >>> apache httpclient, which handles requests synchronously. On the client, >>> POSTs and GETs are sent out sequentially. >>> >>> On Sat, Mar 5, 2016 at 1:57 PM, Russell Brown <russell.br...@me.com> >>> wrote: >>> >>>> >>>> On 5 Mar 2016, at 18:43, Qiang Cao <caoqiang...@gmail.com> wrote: >>>> >>>> > Just curious. The POSTs are sent out sequentially and a quorum is set >>>> up on Riak. I wonder how would it happen that Riak still considers the POST >>>> requests concurrent? >>>> Did you read the result of POST 1 before sending POST 2? If not, and >>>> you don’t send the causal context, Riak has to view them as concurrent. >>>> >>>> How does the quorum work here? >>> >>> Thanks, >>> Qiang >>> >>> _______________________________________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >>
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
