So the coordinators could be made to hang around, replying on quorum and other events, then dispatching an event when everything's been updated? I assume the interested code would register an event hook on the bucket properties like a commit hook?
jb On Feb 28, 2011, at 5:10 PM, Sean Cribbs wrote: > Ah, I misunderstood you. This would be an interesting addition to Riak, but > is not in the current roadmap. The request coordinators currently reply and > exit as soon as quorum is met, even if that's 0, so the replies from the > vnodes never get delivered if the coordinator is gone. > > Sean Cribbs <s...@basho.com> > Developer Advocate > Basho Technologies, Inc. > http://basho.com/ > > On Feb 28, 2011, at 6:08 PM, Jon Brisbin wrote: > >> Correct me if I'm wrong but you write a high-performance app by specifying >> dw=all on every write. I'm thinking something along the lines of "take your >> time inserting the data, just let me know when you're finished". That's >> drastically different from "don't return from this call until you've written >> to every node I might potentially hit with a query". >> >> Sent from my iPhone >> >> On Feb 28, 2011, at 4:55 PM, Sean Cribbs <s...@basho.com> wrote: >> >>> This is handled in Dynamo-style architectures like Riak with quorums. In >>> Riak's case, you rely on the "W" and "DW" quorum values to determine what >>> is an acceptable threshold for considering a write to be a success. By >>> default, W and DW are set to "quorum", which means N/2+1 (for N=3, this is >>> 2) partitions must reply that they both 1) received the write (W) and 2) >>> committed the write to durable storage (DW). This allows you to lose one >>> replica via outage, network partition, or overload and still have 2 copies >>> available for read on the next operation. An interesting side-effect of >>> this is that even though a write may appear to have failed from the >>> client's perspective, some partitions may have succeeded. >>> >>> Sean Cribbs <s...@basho.com> >>> Developer Advocate >>> Basho Technologies, Inc. >>> http://basho.com/ >>> >>> On Feb 28, 2011, at 5:47 PM, Jon Brisbin wrote: >>> >>>> In the midst of a discussion about messaging and eventual consistency and >>>> I'm wondering if there's a reasonable answer to the question: >>>> >>>> Is eventual consistency in a system that needs to know when it can start >>>> querying the system for the just-inserted data not a problem if there is >>>> an event triggered when this checkpoint is reached (like a publisher >>>> acknowledgement) that tells the client "remember that data you inserted a >>>> few cycles back? It's ready to be queried now" and takes the place of a >>>> transaction? >>>> >>>> The concern is that eventual consistency is bad when you need to know for >>>> sure that data was persisted to the store and the system currently uses >>>> transactions to ensure this. >>>> >>>> Thanks! >>>> >>>> Jon Brisbin >>>> >>>> http://jbrisbin.com >>>> Twitter: @j_brisbin >>>> >>>> >>>> >>>> _______________________________________________ >>>> riak-users mailing list >>>> riak-users@lists.basho.com >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> > Thanks! Jon Brisbin http://jbrisbin.com Twitter: @j_brisbin _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
