Hi Matt and all, As I get it from your post, you already have some resolution algorithm at the application logic. So it looks you could activate allow-mult=true and then when concurrent writes happen you can be presented with multiple values in a later GET (these values are called siblings). At that point you can merge them, with your application logic resolution, and PUT back a single resolved value (that hands back the get causal context) that hopefully will remove those siblings and get your state back to a single value.
If you do concurrently these resolutions/merges you might keep getting siblings, but if your resolution algorithm is correct this only means more resolution work and should not lead to any errors or lost data. Actually, if the resolution algorithm is deterministic (as in CRDTs) it can even be pushed inside Riak. I think this is the case for https://github.com/basho/riak_dt ----- Carlos Baquero HASLab / INESC TEC & Universidade do Minho, Portugal [email protected] http://gsd.di.uminho.pt/cbm On 21/05/2013, at 10:17, Michael Johnson wrote: > I'm not sure I am much better off than you my understanding yes. The CRDT > approach simply allows you to retrieve all stored copies and correct them > yourself (riak not making any judgement about what is correct). If you can > write code that knows how to merge the disparate records, then you are safe > and can avoid data loss (but you cannot guarantee that incorrect data will > never be displayed). > > If you write your application such that the client always sends and receives > complete records, then LLW is probably a sane thing because regardless of > anything else, the end user has said, "This is exactly what I want the record > to be". > > If however your client is sends "add foo to the record", you have no way of > knowing what the client thought "foo" looked like (without some additional > data at least). This is where versions, checksums, or timestamps of records > can come into play. Your client can say "add foo to version the record, and > by the way, the version/checksum/timestamp of the record should be X". Now > you can do something smart with that. I'm not saying this is an example that > should be followed, but it is rather just what popped into my head and > certainly needs some revising. Hopefully, that helps point you in the right > direction. > > > > On Mon, May 20, 2013 at 11:38 PM, Matt Black <[email protected]> > wrote: > Dear list, > > What is your take on the conclusions drawn in the following blog post? > > In our setup, we occasionally suffer lost data through simultaneous writes to > the same key - which I mitigate to some extent with locks in the application > layer. In fact, the resolution in the application is essentially like the > "merge" technique he describes with the CRDTs solution at the end. > > http://aphyr.com/posts/285-call-me-maybe-riak > > Would the CRDT approach he talks about replace the locks in my application > layer (where simultaneous LWW causes overwrites of a single object)? > > I suppose I'm left with the feeling that I don't understand enough of the > workings of Riak and the implications of CAP to really understand this post > on my own. > > Anything anyone can offer on the subject would be most appreciated! > > Cheers > > _______________________________________________ > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
