We recently discovered that ZODB3 applications, like Zope 2.6, can
deadlock when run in a system that uses multiple storages. This was a
fundamental design flaw in ZODB that, happily, has a simple fix.
Brian and I are planning to commit these changes to the ZODB3 3.1 and
Zope 2.6 release branches and make them part of an upcoming bug fix
release. This is a slightly dodgy plan, because there is a lot of
code that is being changed for this bug fix. But the problem is
fairly serious and the solution is available now, we'd like to get it
in the hands of users more quickly than ZODB 3.2 and Zope 2.7.
In short, the solution is to sort storages before beginning the
two-phase commit process used by the transaction manager. Since the
two-phase commit occurs during a transaction commit, we know all the
storages that will be used, and, thus, all the locks that will be
acquired. By sorting the locks, we can guarantee that deadlock will
The implementation of deadlock prevention requires changes to the
storage and transaction data manager APIs. Each must now implement a
sortKey() method that returns a string that can be used to sort the
storages. The sortKey must be globally unique; two storages can't
have the same key unless they are the same storage and one storage
must have the same key regardless of when it is used. The sortKey
must be a string, because other objects may not sort in the same order
for all Python versions.
We have provided default implementions of sortKey() for BaseStorage
and Connection. These implementations aren't necessarily correct, but
they will prevent outright breakage if you update to the maintenance
release. BaseStorage uses the __name__ and Connection uses id(). All
storages and data managers should be updated to the new API. The
default implementations may not prevent deadlock in a multi-storage
environment; they only prevent the update from breaking existing code.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -