[Zope-dev] Re: "hasattr" geddon
Michael Dunstan
michael at looma.co.nz
Wed Aug 18 05:31:14 EDT 2004
On 12/07/2004, at 12:29 PM, Chris McDonough wrote:
> 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.
So... it sounds like ZODB will take care of itself in the face of
ReadConflictErrors swallowed by bare excepts (and hasattr's). (Unless
your managing your own transactions.)
One penalty of bare excepts swallowing a ConflictError is running more
code than is needed. The transaction is going to be thrown away
eventually.
Is there problem with seeing bogus exceptions in code after a swallowed
ConflictError?
I'm thinking that when zope catches any exception in a transaction it
should check the state of the transaction to decide if should treat
this as a ConflictError or report the exception it caught.
Consider a contrived example::
def setFoo(self, value):
try:
self.foo = value
except:
pass
self.fooUpdated()
Assume that the except swallows some ConflictError then an exception is
raised from fooUpdated()
but not a ConflictError, lets say a KeyError. Sure, ZODB is tough
enough to look after itself in this case. What about the developer
trying to interpret the KeyError that is written to event.log?
(Hmm... I should really check that is what you could potentially see
with a current Zope :-)
Michael
More information about the Zope-Dev
mailing list