On Jan 22, 5: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 :)
As you noticed below, memcached supports the "add" operator that sets
a value only if the key has no existing value. So, with a little
refinement that could be incorporated into the flow: when the key is
set (i.e. added), the caller would recheck that the addition was
successful with another get before proceeding. The value used could be
a tuple of (timestamp, some-random-long-id). That way the caller can
check that the add() was successful.
>
> 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/
As I also noted previously, this approach is a rudimentary
synchronization technique. It's not fool proof by any means. If more
reliable atomicity is critical even if performance suffers a bit, one
could cook up a REST web service to manage a central lock where the
semaphore is a lock on a physical file. Then, all Django processes
would call this REST service to acquire a lock. The service could even
do all the waiting and would only return when it can deliver a lock.
-Rajesh D
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
