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

[Jeremy Hylton]

On Thu, 2004-02-19 at 14:18, Matt Feifarek wrote:
> So is it "best practice" to do abort() even if no changes are made? Is
> there even a transaction if no changes are made?

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.

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.

I thought we had done something to raise an exception when a closed
connection was involved in a transaction, but I can't find any code to
do that.  (Shane, if you're listening, do you remember?)

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.

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.

Jeremy