On Sat, 2008-10-25 at 15:14 +0200, Hedley Roos wrote:
Additionally when another transaction is already running in parallel, it will see cache inserts from other transactions.
A possible solution is to keep a module level cache which can be committed to the memcache on transaction boundaries. That way I'll incur no performance penalty.
Module-level should be 'transaction level'. You need to implement ZODB's snapshot-ability to provide similar MVCC semantics. The transaction boundary is gonna give you another hard time: two phase commit. Memcache doesn't support transactions at all, so the only way to come up with a minimized risk is to implement a "one phase" data manager which does its work during `vote` and is run as the last data manager in the vote phase. Note that this isn't a good idea in general but works reliable if your backend supports a "one phase commit" (which memcache doesn't seem to do). I'd also avoid putting a generally reusable "tool" package in the place that it uses the "one phase" data manager hack. Generally applications mixing ZODB with other database like MySQL are going to need that "slot". Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development