[ZODB-Dev] shared cache when no write?

[Malthe Borch]

On 13 December 2012 00:31, Dylan Jay <djay at pretaweb.com> wrote:
> What if two or more threads could share a zodb cache up until the point at which one wants to write. This is the point at which you can't share a cache in a consistent manner in my understanding. At that point the transaction could be blocked until other readonly transactions had finished and continue by itself? or perhaps the write transaction could be aborted and restarted with a special flag to ensure it was processed with the cache to itself. As long as requests which involve external access are readonly with regard to zope then this would improve throughput. This might seem an edge case but consider where you want to integrate an external app into a zope or Plone app. Often the external api is doing the writing not the zope part. For example clicking a button on a plone site to make plone send a tweet. It might also improve throughput on zope requests which involve zodb cache misses as they are also IO bound.

This is what I implemented in http://pypi.python.org/pypi/dobbin/.

Basically, since we don't have a copy-on-write semantic available,
code that wants to change objects must "check out" an object before
dirtying it up.

In Dobbin, that's spelled as:

   >>> from dobbin import checkout
   >>> checkout(obj)

That checks the object into a write-mode for that particular thread,
until the execution context ends.

There's a bit more context to this here:

   http://mockit.blogspot.dk/2012/07/fully-versioned-distributed-object.html

Cheers,

\malthe