Thanks for your answer. You're right when you say it's unlikely that 2 threads have the same timestamp, but it can. So it could work for user creation, but maybe not on a more write intensive problem.
Moreover, we cannot rely on fully time synchronized node in the cluster (but on node synchronized at a few ms), so a second node could theoretically write a smaller timestamp after the first node. An even worst case could be the one illustrated here (http://noisette.ch/cassandra/cassandra_unique_key_pattern.png) : nodes are synchronized, but something goes wrong (slow) during the write, then both nodes think the key belongs to them. So my idea of writing a lock is not well suitable... Does anyone have another idea to share regarding this topic ? Thanks, Kind regards, Benoit. 2011/1/13 Oleg Anastasyev <olega...@gmail.com>: > 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. > >
