On 13 December 2012 00:31, Dylan Jay <d...@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
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:
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org