"It is unlikely that both racing threads will have exactly the same microsecond timestamp at the moment of creating a new user - so if data you read have exactly the same timestamp you used to write data - this is your data."
I think this would have to be combined with CL=QUORUM for both write and read. On Thu, Jan 13, 2011 at 9:57 AM, Oleg Anastasyev <olega...@gmail.com> wrote: > Benoit Perroud <benoit <at> noisette.ch> writes: > > > > > My idea to solve such use case is to have both thread writing the > > username, but with a colum like "lock-<RANDOM VALUE>", and then read > > the row, and find out if the first lock column appearing belong to the > > thread. If this is the case, it can continue the process, otherwise it > > has been preempted by another thread. > > This looks ok for this task. As an alternative you can avoid creating extra > \lock-random value' column and compare timestamps of new user data you just > written. It is unlikely that both racing threads will have exactly the same > microsecond timestamp at the moment of creating a new user - so if data you > read > have exactly the same timestamp you used to write data - this is your data. > > Another possible way is to use some external lock coordinator, eg > zookeeper. > Although for this task it looks a bit overkill, but this can become even > more > valuable, if you have more data concurrency issues to solve and can bear > extra > 5-10ms update operations latency. > >
