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 (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 Fulton           mailto:[EMAIL PROTECTED]   Python Powered!        
Technical Director   (888) 344-4332    
Digital Creations

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to