On 7/26/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
FWIW I believe by default at least, open ZODB connections are tied to
the thread which did the opening (they are returned to a pool when
closed and reused, possibly in another thread).  And indeed each
connection does have a cache; caching is one of the primary
responsibilities of a connection object.

See the documentation in ZODB/interfaces.py for "IConnection".

I *think* what is happening here is that you are committing the
transaction devoted to the current connection/thread, and trying to
close a connection that has pending changes from another thread.  So
when you do transaction.abort(), it's aborting the transaction
involving the current thread, not the one associated with the other

That said, I'm not entirely sure what to tell you to do here; there
used to be an API named "setLocalTransaction" or somesuch that
allowed you to control the one-thread-per-connection policy wrt to a
transaction minimally, IIRC.  This API has disappeared, probably
replaced with something more flexible, but I'm not sure what that
is.  I suspect it may have something to do with the
transaction_manager parameter to DB.open() however.

Thanks, using a single transaction manager along with setting
conn._needs_to_join = True right before I close the connection appears
to fix the problem. It's a bit of a hack, but it works.

For more information about ZODB, see the ZODB Wiki:

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

Reply via email to