Thanks, this is all very helpful. I think what I'll do is keep the Riak settings at default and not do anything tricky there.
And then I'll use Redis as a locking manager as described here: http://redis.io/commands/setnx Initially it will just be a single Redis instance but by the time I'm ready for production (quite a long ways off) I'll use either Redis Sentinel for high availability or use Redis Cluster for high availability + auto-sharding / horizontal scalability. That will get me distributed, key level, atomic shared write locking, allowed on any arbitrary Riak key at the expense of higher latency during the write operation. On Sun Nov 18 09:25:43 EST 2012, jeremiah.peschka at gmail.com <riak-users%40lists.basho.com?Subject=Re%3A%20pseudo-atomic%20operations&In-Reply-To=%3CCACJEN2orcJ0N7wUcj9cYmY_xCJ8MwwQ50W2oRcpG40ZDTVRm1g%40mail.gmail.com%3E> wrote: > > > Chiming in on this as well - > > Using lock(username) will work as long as you have a centralized > application server where all creates occur. As soon as you have two systems > involved you can run into the same problems that you'd run into with Riak. > Issuing a lock is, however, a great way to get started if you only plan on > having a single web/app server in front of Riak for a while. > > Once you get your application up and running you can take some time and > research distributed lock servers for your username management. > > Or you can just take the easy route and push all user creates through a > single server. > > --- > Jeremiah Peschka > Founder, Brent Ozar Unlimited > Microsoft SQL Server MVP > > > > On Sun, Nov 18, 2012 at 5:00 AM, Guido Medina <guido.medina at temetra.com > <http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com>>wrote: > > >* Atomicity is always a delicate subject, but it could be resolved with*>* > >either the following solutions:*>**>* 1. Your application can have a > >re-entrant or synchronized lock: *lock(username)*>* { create if not > >present then exit lock; if present then return to user*>* asking for > >another username }**>* 2. Or you could use standard SQL database with a > >dummy table with just*>* one column: username primary key, create and > >lock record on database, once*>* out of the lock you will know if create > >key in Riak or if return back to*>* user to ask for another user name.*>* > > 3. A distributed lock manager:*>* > >http://en.wikipedia.org/wiki/Distributed_lock_manager*>**>* I would go for > >solution No. 1 if running on a single server or No. 3*>* otherwise if you > >can implement it. Or you could start with solution No. 1*>* and migrate to > >No. 3 as your data grows.*>**>* HTH,*>**>* Guido.*>**>* On 18/11/12 03:58, > >Petrushka Petrushka wrote:*>**>* Riak newbie here :)*>**>* I'm building an > >application that among other things includes a*>* traditional Forum, kind of > >like phpBB. I'm working on the data model and*>* wondering how to guarantee > >the uniqueness of a username when a new user*>* registers an account.*>**>* > >Of course, before saving a new username, I will first do a read to make*>* > >sure the key ( username ) is not found.*>**>* But, what I'm worried about > >is what happens if in between the time of*>* the read and the write, two > >separate users connected to different servers*>* (possibly geographically > >apart) try to register a new user with the same*>* username.*>**>* I see > >Riak has conflict resolution built in, but the default mechanisms*>* appear > >to favor the most recent update.*>**>* I actually want the reverse, I want > >to favor the oldest update.*>**>* It seems I could accomplish this by the > >following:*>**>* a) Set allow_mult=true*>* b) always pass in a > >timestamp*>* c) Sleep 1 second for good measure*>* d) Do a read operation > >on the same key. During conflicts, my client will*>* see multiple siblings. > > My client can choose the oldest timestamp and*>* repost that one's > >X-Riak-Vclock to be the canonical one.*>**>* Now all this being said I have > >a couple of other options.*>**>* - For these kinds of essentially ACID > >-like operations (of which this is*>* really the only one I can think of in > >my whole application) I could use*>* another database such as Redis.*>**>* > >- Assuming N-Value is the default of 3, I could set R=3 and W = 3 on*>* > >Reads and Writes. My understanding is that would help in some situations*>* > >but still doesn't really solve this issue (in terms of an atomic lock if*>* > >you will).*>**>* - Or, thinking about it more, the end user really won't > >have any idea*>* that they were the first or not to reserve that username. > >This whole thing*>* is very edge case anyways, as 2 or more people would > >have*>* to independently choose the same username that was available less > >than a*>* second before. I could just use Riak's default conflict > >resolution*>* (possibly even last_write_wins=true). They would never know > >that I am*>* actually assigning the username to the most recent person, > >instead of first*>* person. It strikes me as a little bit unfair in a way > >:) Really it is*>* splitting hairs though.*>**>* But all this said I'd be > >curious on how people are handing these kinds*>* of things and if I'm > >thinking about this issue in a reasonable manner.* > >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
