Florent Guillaume wrote:
Ok I've dug deeper and now understand the problem.
Thanks for the great detective work!
> The root cause is in the multi-databases support.
Or the misuse thereof. :)
The problem is that the Zope startup only closes the main connection it
had on the root database. The first connection to the TemporaryStorage,
created and opened during Zope startup, is never closed, so still is a
synchronizer in its original transaction, but is nevertheless reused in
other transactins, without a proper synchronizer set up.
When a MountedObject needs to be traversed, it tries to find an
existing connection for the new database by doing:
conn = anyjar.get_connection(db_name)
where anyjar is the "parent" connection. If there's a linked connection
for that database, it's returned, otherwise if the multi- database
already has seen the wanted database, it opens a connection from it,
then adds it to the "linked" connections attribute (conn.connections)
and shares this attribute between the two connections.
I that fails, because the connection has never been linked to the new
database (which is the case during startup code), then the
MountedObject code does:
conn = self._getDB().open()
Here _getDB() correctly returns a newly instanciated database, which
has been linked to the other ones in the multi-databases setup (shared
"databases" dictionnary attribute, ultimately coming from
Then open() returns a new opened connection for that database. *BUT*
this new connection is not "linked" to the others (using their
I don't understand why the temporary database isn't part of the multi-database
to begin with. The mounting code should absolutely not try to open the database
connection itself. It should call get_connection on an existing connection
and fail if that fails.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org