Comments on: validates_uniqueness_of does not guarantee uniqueness

By: Hongli

Hongli — Fri, 08 Apr 2011 08:34:54 +0000

I see it as a limitation in SQL. It has no explicit support for “upsert” commands (a name for the concept “update or insert if not exist”, which is what this use case is all about). When those two SELECTs in the above example are being executed, it is impossible to know beforehand whether they are regular SELECTs or whether they’re part of an upsert command. Databases try to optimize for the highest concurrency, therefore they treat them like regular SELECTs and don’t isolate.

Running SELECT … FOR UPDATE on the other hand does work, and it signals the database that an upsert is imminent. However this is a non-standard MySQL extension.

By: Paul Russell

Paul Russell — Fri, 08 Apr 2011 05:44:06 +0000

Can anyone explain /why/ setting the transaction isolation level to serialised doesn’t help here? I’m not really interested in a ‘try it yourself’ response, I’m interested in an explanation that doesn’t involve the database violating the rules of serialised transactions (i.e. that it MUST yield identical results to as if the transactions had been executed separately). The information in this post has propagated far and wide (including here, which is where I picked it up: http://stackoverflow.com/questions/5577562/rails-maximum-number-of-associated-records/5580367#5580367) as a result of being added to the rails docs, and I just can’t get my head around how this can be true! Help!

By: eno

eno — Wed, 04 Mar 2009 17:29:09 +0000

Hell, no, “A good work around is to use a SELECT FOR UPDATE wrapped in a transaction, which will lock the database.”, is a workaround, and a nonworking at that, because

* it breaks any login based on transactions (unless you run a database that supports nested transactions) and
* because it doesn’t work anyways because, erm, it just doesn’t work. Just try it manually in two MySQL consoles in parallel.

what *does* work instead is locking the database, see (if you are interested) the related posts here: http://1rad.wordpress.com/2009/02/23/0×17-atomic-science-revisited/

By: Hongli

Hongli — Tue, 25 Nov 2008 23:59:40 +0000

Fernando, I never claimed I discovered anything. I merely documented it.

By: fernando

fernando — Tue, 25 Nov 2008 23:55:13 +0000

You didn’t discover anything at all. This race condition is known for a long time. I posted something about it 6 months ago at the following link: http://www.ruby-forum.com/topic/154078

A good work around is to use a SELECT FOR UPDATE wrapped in a transaction, which will lock the database.

By: Henrik N

Henrik N — Wed, 29 Oct 2008 12:52:05 +0000

This is how I prevent double submits client-side: http://henrik.nyh.se/2008/07/jquery-double-submission

By: Eric

Eric — Wed, 24 Sep 2008 18:34:31 +0000

Typical Rubyist: If you read my comment, you would see I recommend client-side prevention _in addition to_ backend constraints. On many applications, the client-side component will prevent the vast majority of these problems, making for a much better visitor experience.

As a general rule, it’s a good idea to re-read a comment before you flat out insult it.

By: Hongli

Hongli — Tue, 23 Sep 2008 16:58:11 +0000

Typical Rubyist: it isn’t such a bad idea. Of course it shouldn’t be the *only* protection, but when implemented it can drastically reduce the chance of duplicate inserts.

By: Typical Rubyist

Typical Rubyist — Tue, 23 Sep 2008 15:40:46 +0000

Hahaha use JS to disable doubleclicks? Are you serious? If you rely on client, you will lose.

By: Hongli

Hongli — Mon, 22 Sep 2008 12:36:02 +0000

Fjan, transactions doesn’t help you here, even if you use serializable. Try it out for yourself. Unless user 2′s first SELECT statement blocks until user 1′s transaction has been completed (which PostgreSQL doesn’t do), transactions won’t prevent the duplicate insertion.