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
   >>> 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:



For more information about ZODB, see http://zodb.org/

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

Reply via email to