[Zope-dev] Do I really understanding caching?

[Chris McDonough]

Statement of possible BS: I am speaking from how I understand the
catalog
to work, and possibly not how it actually *does* work. :-)

Andy McKay wrote:
> 
> We have been looking at caching in Zope as a way of tweaking performance.
> Heres an example of what I think happens:
> 
> - Supposing I have a 1,000 object catalog. If one person changes an catalog
> aware object, that instance of the catalog will be pulled out of the ZODB
> and changed. It will then be written to the ZODB. 

Actually, a subobject of the catalog which is stored in a BTree will
change,
and the Catalog instance will change, but it will not write the entire
contents of the catalog back out to the ZODB.  The current BTree
implementation has some problems, so other unrelated objects in it may
be
changed on the write.  This will be solved by updates to the catalog
which use a new "broadtree" BTree implementation.

> That last copy will stay
> in the cache for as long as the "Cache Parameters" are set to allow.

The changed subobjects will, yes.  Unless they're manually ghosted for
some other reason (rarely happens, if ever).

> - If somebody changes another catalog aware object, that will repeat the
> above process.

Yes.

> - However simply accessing the catalog (no changes) will pull the object
> from the cache.

Yes.

> - What would be really nice is if the object only got written to the cache
> when it is no longer used, that way every time the catalog changed it didnt
> write to ZODB instead it changed the cached version. Of course that does
> bring up the recovering from disaster problem.

This would break transactional integrity.  It's important that the
catalog
is in a self-consistent state as well as be consistent with other
objects in the ZODB, and transactions help to maintain this.

Is it essential that all your cataloged objects be catalog-aware?

-- 
Chris McDonough
Digital Creations, Publishers of Zope
http://www.zope.org