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 https://mail.zope.org/mailman/listinfo/zodb-dev
