[ZODB-Dev] Threads and Connections

[Gary Poster]

On Jul 26, 2006, at 12:52 PM, Chris McDonough 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  
> 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.

Open the database with an explicit transaction_manager if you want to  
manage these yourself, instead of using the thread default.

If you have a connection, get the transaction_manager off of the  
connection.  Can't find it in the interface, unfortunately, but I  
believe it to be reliable.

All that said, Chris S, it sounds like you might be attacking a  
solved problem--and *might* be adding some serious unnecessary  
complexity.  Maybe you ought to take a step back and see if anyone  
has a general approach to what you want?  For instance,  you said

>> The reason why I'm doing this is because I'm trying to update the
>> classes of persistent objects loaded into memory.

Want to elaborate on this a bit?  It sounds like stuff other folks  
have done, but you might want to give more detail.

Gary