Le vendredi 7 octobre 2011 10:15:34, Andreas Gabriel a écrit :
> self._update() in the while loop is called (calls indirectly the memcache
> "query" method, a synonym for "get") before the "cas" method is called.
In my understanding from "pydoc memcache", there is "get", which loads, and
"gets" which loads and supposedly does some magic needed by "cas".
Maybe on any "cas"-supporting memcache implementation "get" just does that
I didn't read memcache (client & server) code, but I expect some server-side
flag (?) on the object (?) telling which connection (?) loaded that value
using "gets", flag which would be cleared upon first store on that value (and
de-facto dropped when the value is dropped).
I expect breakages when connection is closed, and when the same connection is
used by multiple competitors for a single lock.
I could not imagine another way this would work so far.
> Please continue your developement because this will be important
> feature/enhancement for big zope sites with many zeo-clients under heavy
Actually I'm not sure how this should be properly tested: testing this
requires reproducing race conditions, and I think one cannot reproduce all
possible race conditions in test cases, even knowing the code...
Of course, I (as an exercise) stay focused on a stand-alone usage, where no
ZODB conflict resolution would help recover from a bug.
ERP5 - open source ERP/CRM for flexible enterprises
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org