[ZODB-Dev] API for dooming a transaction for ZODB 3.3

[Steve Alexander]

dieter at handshake.de
> Casey Duncan wrote at 2004-1-8 13:34 -0500:
> > ...
> >> So, I'm now in favour of never committing a doomed transaction.
> >
> >+1
> 
> I do not think that we should have the effect of dooming
> a transaction without an error message.

I think we are in agreement, when talking about the zodb.

In my latest message to zodb-dev, I proposed that a doomed transaction
will raise a ConflictError if you try to commit it.


> Dooming a transactions is a very disruptive global (with respect
> to the request) operation -- especially when used inside a module.
> 
> It may affect things far outside the scope of the dooming.

I don't see how it can change things outside the scope of the dooming.
It ensures the current transaction cannot be committed. The whole point
of transactions is that anything important within their scope either
happens or does not happen depending on whether the transaction commits
or not. The scope of the dooming is the scope of the transaction.


> Why can you not raise a special exception that you can handle
> in a special way inside your error page?

That's a Zope issue, not a ZODB issue.

I'd like to focus on getting a 'dooming' API into the ZODB.

If this API were in the ZODB tomorrow, and with no further changes to
Zope, calling doom() works just like having a conflict error that is
caught and does not reach the publisher. The request will continue to be
processed as normal, but when the publisher tries to commit, a conflict
error will be raised.

Changes to Zope would be required only if people want to use dooming as
part of the error handling in their application, and have Zope treat
these cases differently.

--
Steve Alexander