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 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
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to