[ZODB-Dev] State of persistent cache after commit

[Tim Peters]

[Tim Peters]
>> Try playing with the DB constructor's optional cache_size argument.  It
>> defaults to 400, meaning that a cache-eviction pass will try to boot out
>> all but 400 objects.  That fits the symptoms you describe.  DB instances
>> also have getCacheSize() and setCacheSize(new_cache_size) methods.

[Christian Robottom Reis]
> Interesting. This is something that could be done for both ZEO client and
> server, which beckons the question: is it useful in both situations, or
> is this a client-side only issue?

AFAICT, client-side only.  The ZEO server implements the storage API, and
doesn't use DB -- the server side doesn't *have* a memory cache in the sense
that a client does.  If, for example, a ZEO server is managing a
FileStorage, then the FileStorage implementation holds various in-memory
caches and indices, but they're at the level of oids and file offsets, not
objects.  Indeed, a ZEO server doesn't generally have access to application
classes, so it can't have an object cache (the server has pickles, which get
unpickled on the client side).