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: http://mockit.blogspot.dk/2012/07/fully-versioned-distributed-object.html Cheers, \malthe _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
