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
