Comment 17 for bug 98382

Thanks for doing the practical experiment, Gary.

So, for a web application, it seems to me that:

 - the publication is responsible for starting, committing and aborting transactions.

 - application code spread around wherever is responsible for dooming translactions. application code should never start, commit or abort a transaction.

 - self-contained units of application code can use savepoint and rollback, but the developer needs to be aware of the codepath that occurs within the savepoint->rollback, or expect that an InvalidSavepointRollbackError may be raised on rollback(). It will often be safe to simply ignore this error, because the publication will be aborting anyway.

It would be nice if there was a specific subclass of InvalidSavepointRollbackError that is a DoomedTransactionRollbackError. Then I could write code that does:

    try:
        transaction.rollback()
    except DoomedTransactionRollbackError:
        # hmm, was doomed during the savepoint.
        goto SKIP_OTHER_PROCESSING

Actually, we can do that anyway by saying:

    except InvalidSavepointRollbackError:
         if transaction.is_doomed():
             goto SKIP_OTHER_PROCESSING