On Sat, Feb 6, 2010 at 8:55 AM, Malcolm Box <malcolm....@gmail.com> wrote:

> 2010/2/5 Jared Smith <jaredtsm...@gmail.com>
>
>> My use case is that I'll have multiple users trying to update a set of
>> objects and I want to make sure that any user committing a change has
>> knowledge of the existing state.  I was going to model that with a version
>> number so an update would look like:
>>
>
> Maybe I'm missing something, but this sounds like the canonical use of
> ETags.  Provide an Etag with the read, then when the update comes in check
> if the ETag matches what is calculated for the current state of the DB.
>
> If it does, let the update through.  If not, then force the user to retry
> based on the new state.
>

Note anything done like this in Django app code is liable to run into
multi-thread/multi-process race conditions. A typical production deployment
environment will have multiple threads and/or processes handling requests
simultaneously. Thus current state of the DB when a request is received is
not necessarily going to be the same as current state of the DB by the time
the request processing thread gets around to actually making the update --
one request processing thread could have already passed the point of
accepting an update but not quite gotten around to making the change in the
DB when a 2nd request processing thread decides it's also OK to accept an
update. Last one to actually issue the update wins, the other thread's
update is lost.

Using an atomic SQL UPDATE with a WHERE clause specifying the version
requirement, which is what QuerySet update() allows, pushes the
responsibility for dealing with this race condition onto the DB. The DB will
ensure that only one of the threads gets to make the update, and the Django
app code can know which it is based on the result of the update() call.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to