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

[Steve Alexander]

>>This is particularly useful in Zope applications when an error occurs in 
>>an application, and you want to ensure the transaction will not be 
>>committed, but you don't want to present the exception to the user.
> 
> 
> I'm having trouble convincing myself that this should be a feature of
> Transaction objects.  The idea could be implemented like undo, abort
> version, and commit version:  Implement a simple data manager that
> performs the desired behavior during 2PC.  

Yes, I guess that would work.


> Perhaps the problem is that there needs to be more coordination that
> get_transaction() provides.  That is, if some code calls abort() or
> commit(), then future calls to get_transaction() returns a new
> transaction object.  One possible solution there is to distinguish
> between getting the current transaction and getting a new
> transaction -- for example, get_transaction() vs. new_transaction();
> if you call get_transaction(), you get the current transaction, in
> progress, aborted, or committed.  Then you wouldn't have later code
> accidentally starting a new transaction, although you could still have
> the problem with code that intentionally created a new transaction.

I think it is good to distinguish between starting a new transaction and 
continuing to use an existing transaction. I've bumped into the problem 
when debugging a test suite where some tests didn't properly clean up 
after themselves. The change you suggest would have made the problem a 
lot more obvious.


--
Steve Alexander