[ZODB-Dev] Webkit Threading and ZODB 3.3a2: problems on Windows

Matt Feifarek matt at dalchemy.com
Thu Feb 19 17:41:55 EST 2004


Dieter Maurer wrote:

>It is a very good idea to always finish a request with a call
>to either "commit" or "abort".
>
>Otherwise, the next request can get a connection with objects in
>an undefined state. If it gets a different thread id (than
>the previous request that used this connection), a commit
>of this (new) transaction will not be able to make objects
>with "_p_changed=1" persistent (as they are registered with a
>different transaction).
>
Why would an object that has not been changed be in "an undefined 
state"? Why would it be registered in a transaction at all?

Plus, from what I've been hearing, the transaction is tied to a thread, 
not to a connection... so the thread id should never change... right?

But what you're describing "sounds like" what we're seeing... so I'd 
like to understand what you mean.

If, like you said, it's a good idea to always run .abort() or .commit(), 
we can certainly do that. In fact, that's our workaround on windows 
right now. Is that the "right thing to do"? The ZODB docs certainly 
don't say that; maybe it should be added?

Thanks, Dieter!



More information about the ZODB-Dev mailing list