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

[Steve Alexander]

> What would be appropriate?
> 
> I am suprised you dont want a cleaner separation, and handle this entirely 
> within the transactional system. Why should the publisher get involved at 
> all?

Usually, read conflict errors interrupt an applications control flow,
and end up being caught by the publisher. The publisher knows what to do
in that situation. I think the usual recipe for any error in Zope 2 is to
abort the transaction and then retry the request, or to fail with an error
if the request has been retried several times already.

Sometimes an application will catch a read conflict error. In these cases, the
publisher will not have caught the exception. However, a conflict error will
be raised when the publisher tries to commit the transaction. This is
fine in Zope because the publisher will catch the error, abort the
transaction, and then retry the request.

In the use-case that was given, after some application error, the
application should be allowed to continue processing the request, and to
return a normal response for that application. But, the transaction
should be aborted. In this case, the publisher should not treat the
failed commit() as an error. The publisher should note that the
application asked for the transaction to be doomed, and abort the
transaction rather than commit it.


I think there are two different cases of wanting to doom a
transaction from a Zope application.

1. Like with the read conflict error, you want to have the request retried.
   You also want to ensure that the transaction will not be committed.
   You do not want to abort the transaction immediately, beacuse that
   implicitly starts a new transaction.

2. The same as in case 1, except that you do not want to have the
   request retried. You want the publisher to abort the transaction,
   and to return a normal application response, not an error page.

In both cases, the transaction is doomed. Each case requires different
treatment from the publisher.

I can think of three ways of getting the information about how to treat
a particular case of dooming to the publisher.

a. Have some kind of get_publisher() function that uses the current
   thread as a key to look up the current publisher.

b. Allow the transaction's doom API to handle some extra information about
   the desired semantics of the dooming.

c. Introduce a Zope-specific API that applications use to doom the
   request. This API calls get_transaction().doom(), and also records
   information for the publisher, keyed on the current transaction.
   The publisher uses the Zope-specific API to find out the extra
   semantics.


Of these three, I propose [c]. It adds a simple dooming API to
transactions, and keeps the Zope-specific stuff separate.

--
Steve Alexander