[Zope-dev] Re: "hasattr" geddon

[Chris McDonough]

FWIW, as far as I understand the "prevent commit on conflict" behavior
*is* currently the behavior for caught ReadConflictErrors.  The only
time ZODB doesn't exhibit this behavior is *during the commit of a
transaction*.  If a commit is attempted at this point and a conflict
error is caught unintentionally, the following happens (as explained by
Tim at http://mail.zope.org/pipermail/zodb-dev/2004-May/007404.html :

- the attempt to commit fails, raising a write conflict error

- the write conflict error is unintentionally caught (whether by hasattr
or a bare except or by whatever)

- a new transaction begins implicitly (as if "get_transaction().abort()"
or "get_transaction().begin() were called)

- ... whatever happens after this happens ..

Since it's extremely unlkely for a write conflict error to be caught
unintentionally in Zope (it would require an application to perform a
"get_transaction().commit()" going outside the boundaries of the default
transaction manager), it's an obscure failure mode.

If the transaction was not put into a committable state after a caught
exception error, there would be no problem.  But to be fair, I don't
think there is much of a problem right now, as very few Zope apps manage
their own transactions (except for the Catalog... gulp ;-).  But it
would be nice if ZODB didn't do the implicit "get_transaction().abort()"
after a write conflict error and left the transaction in an
uncommittable state instead... or at least had an option to do this.

- C


On Sun, 2004-07-11 at 19:47, Shane Hathaway wrote:
> On Saturday 10 July 2004 20:54 pm, Casey Duncan wrote:
> > Shane Hathaway <shane at hathawaymix.org> wrote:
> > > Why are
> > > we fixing hasattr and bare excepts when the real problem is ZODB?
> >
> > Well, the real problem is *probably* people, but I digress...
> 
> http://c2.com/cgi/wiki?TheProcessIsTheProblem ;-)
> 
> > Still, swallowing read conflicts can lead to bugs, even in read-only
> > tranactions. Consider the following function:
> >
> > def getStuffFrom(ob, default):
> >     if hasattr(ob, 'stuff'):
> >         return ob.stuff
> >     return default
> >
> > I have seen this idiom about in some zope application/framework code. If
> > the hasattr results in a read conflict, then it returns false and
> > default is returned by the function even if ob does have the attribute.
> > In the example I saw (in DCWorkflow) this would result in the wrong UI
> > elements being displayed for ob mysteriously. Reloading the page would
> > likely fix the problem, baffling both the user and app developer, who
> > now both think Zope is playing with their minds.
> 
> The change to ZODB that I'm suggesting would fix this.  The suppressed 
> conflict error would still mark the transaction as uncommitable.  When the 
> publisher calls commit() (which it does on every request even if nothing 
> changed), it would result in a ConflictError, then the publisher would call 
> abort() and the transaction would be retried.  Users would never see results 
> from a transaction that had any conflict.
> 
> Shane
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>