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: https://github.com/vpelletier/python-memcachelock 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. Regards, /me falls asleep on keyboard -- Vincent Pelletier _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev