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.