Hi Simon,
many thanks for your reply!
Please see below for some follow-up questions.
Am 11.05.2016 um 16:04 schrieb Simon Charette:
Did you try using select_for_update() with get_or_create()[1] in an
atomic()[2] context?
@transation.atomic
def demonstrate_the_problem():
d = date.today()
t = TestModel.objects.select_for_update().get_or_create(
jahr=d.year, monat=d.month
)
# ... long `some_value` computation
t.some_value = 123
t.save(update_fields={'some_value'})
return t
Note that in this case if another thread tries to select_for_update() it is
going to block at the get_of_create() until the first thread's transaction
commits.
Why will the other thread block?
(Both threads may enter the "create" case, so the select_for_update() may not
yet be effective for the other thread?)
I looked into get_or_create()'s source code and the _create_object_from_params()
method that it calls. Is this due to the "second"
return self.get(**lookup), False
near its end?
Also, I understand the purpose of wrapping demonstrate_the_problem() in
atomic(), accounting for possibly unrelated exceptions in "long `some_value`
computation". But why does _create_object_from_params() wrap its single call to
`create()` in atomic(), too? Isn't create() inherently atomic?
Best regards,
Carsten
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5734979A.7050608%40cafu.de.
For more options, visit https://groups.google.com/d/optout.
