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.
On Sun, 2004-07-11 at 19:47, Shane Hathaway wrote:
> On Saturday 10 July 2004 20:54 pm, Casey Duncan wrote:
> > Shane Hathaway <[EMAIL PROTECTED]> 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.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -