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

[Matt Feifarek]

Jeremy Hylton wrote:

>I'm not sure I understand exactly how you're managing Webkit threads and
>ZODB transactions, so it's hard to be confident with the advice I'm
>giving.  If you've got some code you can point us at, that would be
>great.
>  
>
I'll try and whomp up a simple case... after following this conversation 
a bit more. I think that we're closing in on the answer. (Thanks again!)

>ZODB associates a Transaction object with a thread.  Modified objects
>register themselves with their thread's current transaction.  If you
>modify an object in between calling commit() and closing the connection,
>you will have problems.  The next request to run in that thread will
>pick up a transaction that is already populated with objects from a
>closed connection.
>  
>
We can be nearly certain that nothing is modifying objects after 
commit()... unless ZODB is doing something very deep down that we have 
no control over.

So I'm gathering that there is always a transaction, even if nothing has 
changed. And re-using it is dicey.

It seems that the fact that this goes away if we .abort() every time is 
a good clue...

>One solution is to find out what code is modifying objects but not
>committing them and fixing it.  I think that's got to be the root cause
>of the problem.
>  
>
If that were the problem, wouldn't we see it on linux, too? Or the case 
of a single thread setup?

>Another possibility is to call ZODB.Transaction.free_transaction() when
>you close the connection.  That will delete the Transaction object that
>holds the registrations from modified objects.  This approach feels more
>like a band-aid than a fix.
>
Agreed. But it sounds thorough! ;-) Would there be a performance hit to 
that?