Re: [Zope-dev] Re: "hasattr" geddon
On Saturday 10 July 2004 20:54 pm, Casey Duncan wrote:
Shane Hathaway <shane@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
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@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@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 )
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
participants (3)
-
Chris McDonough -
Michael Dunstan -
Shane Hathaway