Sorry I took so long to reply. "Randall F. Kern" wrote:

[Originally sent to zope-dev, but belongs here]

I'm CCing zope-dev, since you posted there too.

I may just be missing something obvious here, but it seems like there is a hole in ZODB.Transaction.Transaction.commit and Shared.DC.ZRDB.TM.TM, that can cause external transactions (those that use the TM mixin class, like psycopg) to be abandoned (never get committed or rolled back).

Let's say somewhere around line 300 in Transaction.py (the call to j.commit(o, self)) we get an exception. Furthermore, let's say the TM derived database object has already been committed (the only effect of which is to move the DB into the jars mapping, since TM.tpc_begin() and TM.commit() both do nothing).

The exception dumps us down to about line 353, where we call _p_jar.abort() on all the uncommitted objects (note: it's important that the database connection isn't in this list, because TM.abort() will rollback the transaction. the way we keep the db out of this list is by having it appear in objects _before_ the object that failed the commit).

Next we reach line ~366, where we should "unwind TPC for the jars that began it". What this means is calling tpc_abort() on each jar from the objects that were already committed (which includes the database). However, TM.tpc_abort() does nothing, leaving the external database transaction open.

Does this make sense?

Yup, fraid so.

If this makes sense (i.e. seems bad :), does catching tpc_abort() in TM and calling TM.abort() seem like a valid fix? This change certainly seems to fix the problems.

Yes. I think this is an improvement. Thanks. I'll check this in. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org