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 connection.

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.

- C


On Jul 25, 2006, at 11:40 PM, Chris S wrote:

The problem is the only objects I need to grab are the ones loaded by
other connections. I use Python's garbage collector to track
references to instances of classes that have been updated. Aside from
the strange error below, the live update functions correctly. It's
almost like the connection is keeping a special cache that's
conflicting with the new objects.

Chris

On 7/25/06, Mika, David P (GE, Research) <[EMAIL PROTECTED]> wrote:
I don't know the answer to your question, but when I have separate threads,
I always have each thread independently control their own connection
(open and close).  Perhaps in your situation, you could have the
update function open it's own connection, grab the object in question
from the ZODB, change it, commit it and close.
Dave

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Chris S
Sent: Friday, July 21, 2006 6:29 PM
To: zodb-dev@zope.org
Subject: [ZODB-Dev] Threads and Connections


Is it possible to close a connection used in one thread from another
thread? My program has a locking mechanism, so I can ensure threads
don't use their connection while it's closed, but whenever I try to
close one thread's connection from another thread, I get errors like:

    self.conn.close()
  File "C:\Program
Files\Python24\lib\site-packages\ZODB\Connection.py", line 252, in
close
    self.transaction_manager.unregisterSynch(self)
  File "C:\Program
Files\Python24\Lib\site-packages\transaction\_manager.py", line 169,
in unre
gisterSynch
    ws.remove(synch)
  File "C:\Program Files\Python24\Lib\site-packages\ZODB\utils.py",
line 236, in remove
    del self.data[id(obj)]
File "C:\Program Files\Python24\lib\UserDict.py", line 19, in __delitem__
    def __delitem__(self, key): del self.data[key]
KeyError: 26403280

The reason why I'm doing this is because I'm trying to update the
classes of persistent objects loaded into memory. I'm able to load the
new classes just fine, but when I try to close the connection at
program termination, I get the error:

transaction.commit()
conn.close()
ConnectionStateError: Cannot close a connection joined to a transaction

The only way I'm able to avoid this strange error is if I close all
connections during the update, but since my update function runs in a
different thread, it can't close the connections. Is there a way
around this, or am I misunderstanding something?

Chris
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to