in ZEORaid recovery we acquire the commit lock of our RAIDStorage from a
thread to be able to finish recovery atomically.

That RAIDStorage is also being served from a StorageServer which causes
some trouble because it assumes that the only way for a transaction on
the served storage to end is via the StorageServer's tpc_abort or
tpc_finish method.

Thus, when a transaction comes in while the recovery has a transaction
going on the StorageServer puts it into the waiting list but never gets
the signal to continue.

Reading the code talking to tpc_transaction I found that this seems to
be merely an optimization (which I can disable by just letting
tpc_transaction return None all the time).

Why is the waiting list necessary? And why does it work alright in a ZEO
fan-out scenario?


Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

For more information about ZODB, see the ZODB Wiki:

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

Reply via email to