[ZODB-Dev] State of persistent cache after commit

[Tim Peters]

[Rad Widmer]
> It is my understanding that the persistent object cache is invalidated
> after a commit.

I'm not sure what that means to you, but my best guess is that what you
think it means doesn't actually happen.  After a commit, invalidations are
sent *out* for objects modified by the transaction that committed, and
invalidations *from* other transactions are processed.  Invalidation only
affects modified objects, not objects that are merely read.

> Is there a way to prevent this from occurring?

No.

> If so, is there a downside to doing so?

Sending and processing invalidations at transaction boundaries are
fundamental requirements for maintaining data consistency.

> Memory usage is not a big issue for me right now. In my application, I
> typically load a large number (> 100,000) of small objects, then modify
> a small number of these. After a commit, I typically see long delays
> because many objects need to be reloaded.

Typically see long delays where, specifically?  Showing actual code would be
best.

I'll guess, though:  one thing that happens after a commit is that an LRU
cache-eviction pass is run, to reduce the database connection's in-memory
cache to its configured size.  That's got nothing to do with invalidation,
but will ghostify objects even if they've merely been read.

> I'm running ZODB 3.3.0c1.

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.