Le jeudi 06 octobre 2011 21:18:39, Andreas Gabriel a écrit :
> Maybe this code will help as example for the shared locking problem
> https://svn.plone.org/svn/collective/unimr.memcachedlock/trunk/unimr/memcac
> hedlock/memcachedlock.py

I couldn't resist writing my own version inspired from your code:

It lacks any integration with ZODB.
It drops support for non-"cas" memcached. I understand your code relies on 
ZODB conflicts as last resort, but I wanted to scratch an itch :) .
It drops support for timeout (not sure why they are used for, so it's actually 
more a "left asides" than a drop).
It moves the "uid" problem from random generator to a hope that no instance 
will survive 2**32 instanciation of other instances for a single lock. I feel 
somewhat safer that way.
It does a super-minor optimisation: the key won't change in instance life, so 
hash it once and use the 2-tuple form for memcache's key parameter.

I admit this is my first real attempt at using "cas", and the documentation 
mentions gets must be called before calling cas for it to succeed. I don't see 
gets calls in your code, so I wonder if there wouldn't be a bug... Or maybe 
it's just my misunderstanding.

As the README states: it's not well tested. I only did stupid sanity checks (2 
instances in a single python interactive interpreter, one guy on the keyboard 
- and a slow one, because it's late) and a pylint run.

/me falls asleep on keyboard
Vincent Pelletier
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to