On Sat, 2008-10-25 at 14:53 +0200, Hedley Roos wrote: > > I'd love if this wouldn't be a monkey patch. > > So would I, but I couldn't find another way in this case. > > > > > Also, there is nothing that makes this integrate correctly with > > transactions. Your cache will happily deliver never-committed data and > > also it will not isolate transactions from each other. > > > I patched 4 methods - clear, search, catalogObject, uncatalogObject. > > Method clear is the simplest one - I simply flush the cache.
This is probably harmless but will cause unnecessary cache flushes for other clients. > Methods catalogObject and uncatalogObject both invalidate the cache. > Should the transaction fail later the only drawback is that you threw > a few things out of the cache. They'll soon be re-entered by > subsequent searches. Right. This is the same as clear. > Method search just inspects queries and stores results to memcache. That's the issue. If you catalog an object, then search for it and then abort the transaction, your cache will have data in it that isn't committed. Additionally when another transaction is already running in parallel, it will see cache inserts from other transactions. 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
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 )
