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 _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
