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.
