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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
