[ZODB-Dev] State of persistent cache after commit
Tim Peters
tim at zope.com
Wed Oct 20 14:32:32 EDT 2004
[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.
More information about the ZODB-Dev
mailing list