Re: [Zope-dev] External transaction integration bug?

2001-04-19 Thread John D. Heintz

I can't directly address the concerns you've raised, but for my project 
I have rewritten TM.py to work better within the begin/vote/finish/abort 
protocol framework.  I've also added more documentation.

John

Randall F. Kern wrote:

> 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?
> 
> If this makes sense (i.e. seems bad :), does catching tpc_abort() in TM
> and calling TM.abort() seem like a valid fix?
> 
> Thanks,
> -Randy
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
> 
> 
> 




##
# 
# Zope Public License (ZPL) Version 1.0
# -
# 
# Copyright (c) Digital Creations.  All rights reserved.
# 
# This license has been certified as Open Source(tm).
# 
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# 
# 1. Redistributions in source code must retain the above copyright
#notice, this list of conditions, and the following disclaimer.
# 
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions, and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 
# 3. Digital Creations requests that attribution be given to Zope
#in any manner possible. Zope includes a "Powered by Zope"
#button that is installed by default. While it is not a license
#violation to remove this button, it is requested that the
#attribution remain. A significant investment has been put
#into Zope, and this effort will continue if the Zope community
#continues to grow. This is one way to assure that growth.
# 
# 4. All advertising materials and documentation mentioning
#features derived from or use of this software must display
#the following acknowledgement:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#In the event that the product being advertised includes an
#intact Zope distribution (with copyright and license included)
#then this clause is waived.
# 
# 5. Names associated with Zope or Digital Creations must not be used to
#endorse or promote products derived from this software without
#prior written permission from Digital Creations.
# 
# 6. Modified redistributions of any form whatsoever must retain
#the following acknowledgment:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#Intact (re-)distributions of any official Zope release do not
#require an external acknowledgement.
# 
# 7. Modifications are encouraged but must be packaged separately as
#patches to official Zope releases.  Distributions that do not
#clearly separate the patches from the original work must be clearly
#labeled as unofficial distributions.  Modifications which do not
#carry the name Zope may be packaged in any form, as long as they
#conform to all of the clauses above.
# 
# 
# Disclaimer
# 
#   THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY
#   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
#   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
#   PURPOSE ARE DISCLAIMED.  IN

[Zope-dev] External transaction integration bug?

2001-04-18 Thread Randall F. Kern

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?

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

Thanks,
-Randy

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )