On 12 elo, 18:41, "Cal Leeming [Simplicity Media Ltd]" <[email protected]> wrote: > *C) Execute a commit before each get_or_create() call* > > It is worth noting that committing the transaction prior to calling > get_or_create() has given our apps a 100% success rate in preventing this > race condition, where as previously the app wouldn't even last 60 seconds > without throwing an IntegrityError exception. > > So although this approach is not fool proof (as you detailed in your > earlier threads), it has been close enough to prevent the problem from > happening in our use case.
I have been long wondering how come users hit this race condition so often. But now it is clear: the problem isn't usually that the second get can't see the DB state, it is the first get that doesn't see the already existing instance. As such, committing before each get_or_create() should fix the issue for most users, just running short transactions would usually be enough. But, I really do think the correct fix for this is to allow using different isolation levels per transaction. As for the get_or_create(): I don't think we can do much else than to document this. I am not sure suggesting use of non-default isolation level globally is a good idea, but just suggesting using short transactions and repeat the transaction on integrity error would be a good start. Later on we could then suggest use of READ COMMITTED for the transactions containing get_or_create(). Option B) seems scary to me. I am not sure but wouldn't issuing such commands confuse the backend library, that is the lib thinks the isolation level is REPEATABLE READ, but it was changed to READ COMMITTED behind its back. If so, surprising bugs might arise. Autocommit (option D) will not help if the get_or_create() is ran in transaction. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
