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!)


For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to