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 
magic too.

More thoughts:
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
> load.

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...

Ideas ?

Of course, I (as an exercise) stay focused on a stand-alone usage, where no 
ZODB conflict resolution would help recover from a bug.

Vincent Pelletier
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

Reply via email to