After some asking around, I suspect that any activity on the immutability front will have to wait until we've rolled strong consistency capabilities into Riak.
Scott Fritchie pointed out something I hadn't considered: even with pw/pr values, it's still possible to end up in an inconsistent state after a partition heals, because a pw write that fails will still result in the new value being written to secondary vnodes. If you write to the "wrong" side of a partition, the write will report to the client as a failure (assuming pw=2) but the values will still be sitting on secondary vnodes waiting for handoff, at which point they would overwrite the primary vnode values, assuming the timestamps dictate that. So if you want to do this in Riak, you definitely should plan on siblings and client resolution, but I think your best bet is going to be to use a different solution than Riak for this part of your system. It's simply not a good fit when you need something approximating strong consistency. -John On May 19, 2013, at 10:44 PM, Jeremy Ong <[email protected]> wrote: > Thanks and yes, for the case of the user creation example I gave, I am > setting pw=pr=quorum. > > Immutable values is a much better way of putting it, although I technically > need deletion as well for this particular example. > > Cheers, > Jeremy > > > On Sun, May 19, 2013 at 7:24 PM, John Daily <[email protected]> wrote: > A few quick thoughts... > > We're tackling a very similar problem (perhaps even the identical problem) > with user accounts in Riak CS via the Stanchion subsystem. I know that > started out as a component running on a single node to avoid conflicts like > this, but I believe it is evolving into a more sophisticated solution. > > This feels like a feature request for allowing keys to be created with > immutable values. I would assume that topic has arisen before, but I'm not > aware of when or whether it's something we've seriously considering > implementing. > > Certainly one would have to be careful with sloppy quorums: in the event of a > network partition, with default settings it would be possible to create > identical keys on different parts of the cluster without an immediate > conflict. You should make certain the primary vnodes are always required by > specifying pw=quorum and pr=quorum (which would mean that attempting to write > the same key in a partitioned scenario would fail unless a majority of the > primary vnodes are reachable). > > Hopefully someone else who's given this some thought in the past will jump > in; I'll make further inquiries tomorrow. > > -John Daily > Technical Evangelist > > On May 19, 2013, at 7:29 PM, Jeremy Ong <[email protected]> wrote: > >> For automatic conflict resolution, often times, the easiest thing to do is >> impose a Last Write Wins policy. >> >> However, in certain circumstances, First Write Wins makes more sense. For >> example, suppose you are handling user creation. Creating a single user will >> populate values for two keys: >> >> User Id => User data >> Username => User Id >> >> A unique User Id is generated to accommodate future username changes. In the >> event that another user attempts to create an account simultaneously with >> the same username, a conflict will exist. The easiest thing for me to do >> here, is after the account is created, check the username to see if it >> points to the correct User Id. If so, return a success message. Otherwise, >> rollback changes to the first key. >> >> I'm OK with last write wins for now, but is there a way of imposing a simple >> first write wins policy without needing siblings and client conflict >> resolution? >> >> Cheers, >> Jeremy >> _______________________________________________ >> 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
