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 · [EMAIL PROTECTED]
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

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to