YES There was a problem with atomic operations. But the add from memcached looks to be atomic: "adds to the cache, only if it doesn't already exist".
P1 and P2 both try to add "thisModelInstance_lock", only one will make it. Busy loop (or sleep for a minimal amount of time), trying to add it. Whichever can add the value first continues onto the code and removes it from the cache so the other can proceed. I'm going to try to make this. If it works, it should be a pretty clean inter-process & inter-server mutex that is fast and doesn't require disk access. Thanks! Ivan On Jan 22, 2:41 pm, Jonathan Ballet <[EMAIL PROTECTED]> wrote: > Le Tue, 22 Jan 2008 14:18:53 -0800 (PST), Rajesh Dhawan > <[EMAIL PROTECTED]> a écrit : > > > - Before you execute lines of code that need to be synchronized > > between processes, read mylock from memcached and set it to the > > current timestamp if it's null. > > ... and bam, another process access the lock when it was still null, > and both processes set it to a timestamp :) > > I don't really know memcached, but maybe it's API provide some > way to avoid race conditions (maybe the 'add' function [1] from the > memcached API). > > [1] see "What about race conditions?" inhttp://www.danga.com/memcached/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
