I certainly do not know much about ZODB internals, therefore I do not
know if this idea make much sense. But it has been bothering me for some
Current ZODB design creates a separate cache for each ZODB connection
(ie. a thread in zope). It means that the same object could be
replicated in each connection cache. We cannot do much about it since we
do not know in advance that a particular object will not be modified.
But it is a kind of waste when a number of modified objects is
relatively low to a number of read-only objects.
Two level cache:
A current ZODB cache will become a first level cache (L1), each ZODB
connection maintains its own copy. When an object is needed it reads it
from L2 cache instead from a storage. L2 cache is a common for all ZODB
connections. Objects are stored there in the state where references are
not yet resolved from their persistent form.
We can still have the same object replicated in respective L1 caches,
now even one more copy is in L2. But a large L2 and a smaller L1 could
possibly lead to a more efficient caching strategy than it is now.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org