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 time.

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.

Atmasamarpan Novy

For more information about ZODB, see the ZODB Wiki:

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

Reply via email to