Ivan Sagalaev wrote: > > Actually there is a common solution to this problem that doesn't create > duplicates and doesn't fail on second transaction. And as James > correctly has noted it works on database level. The solution is a form > of SELECT called SELECT FOR UPDATE. When one transaction selects > something explicitly for update any other transaction trying to do the > same thing will wait until the first one ends. I.e. it works like a lock > for threads but since it works in database it works for multiple Python > processes that otherwise don't know anything about each other. > > The good part is that SELECT FOR UPDATE is implemented in MySQL, > PostgreSQL and Oracle. I recall Malcolm has ones said that Adrian > expressed desire to have this in Django and it might happen after > queryset refactoring. Malcolm, Adrian, please confirm is this correct or > I'm just hallucinating :-) > > It's my understanding that SELECT ... FOR UPDATE only locks the rows that it reads (so you can be sure they can be updated or referenced later in the same trasaction). However, in the case of get_or_create(), there is no existing row, so there's nothing to lock and thus the problem still exists. If it has a fallback to locking the whole table when no row is found (which I don't see in the docs) then it would have worse performance in the create case since I'm only interested in preventing duplicates, not serializing the processes.
Travis --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
