When an application using ZEO tries to load a persistent object:
1. It first looks in the ZODB cache.
2. If that's a miss (the object is not in the ZODB cache),
it consults the ZEO cache.
3. If that's a miss too (the object isn't in the ZEO cache either),
it asks the ZEO server for the object's state.
So wrt the ZODB cache, the ZEO cache is a second-level cache. The
ZODB
cache has a least-recently used replacement policy, and the hope is
that
not-recently-used objects that have been booted from the ZODB cache
can
usually still be found in the ZEO cache, saving the usually much
greater
expense of fetching state from the ZEO server over the network.
This is very helpful thanks!
In my setup I have zeo and zope on the same box. I'm using zeo
because several data loader applications are populating the
database. I wan't these to use the same db as zope so I have been
using the same config file (they aren't zope instances just daemons
that do the import Zope2; app=Zope2.app() thing). Until I tried to
turn on persistent caching this has never been an issue (but I
understand now that its most likely not a good idea).
Because everything is on the same box I don't think I'm getting much
by having the ZEO cache, but maybe its quicker to load from the cache
then to use the zeo protocol to pull objects from the database on the
same box? I and there is the issue of cache maintenance at startup.
I will play around with it a bit now that I understand the
relationships of the caches (and how to use the persistent caching
properly!)
-EAD
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
