[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Dieter Maurer]

Tim Peters wrote at 2004-9-8 22:31 -0400:
>[Tim, on magically getting a new transaction when commit() fails]
>> But that's not how it works, and God only knows what would break if it got
>> changed.  It works that way in 3.3 too, although there you truly (not just
>> "effectively") get a new transaction after a commit() attempt.
>
>So what do people think about this for 3.3?  It's still in beta, so it's
>still *possible* to change 3.3's default TransactionManager to one that
>doesn't magically dump you into a new transaction if the current
>transaction's commit() fails.  People who know far more about Zope than I do
>(like Chris and Shane) consistently say they want that.  I know a number of
>ZODB tests would fail, but I don't care about that -- they're not *relying*
>on the current behavior, they're testing to make sure it stays broken
><wink>.

I do not understand why you want to keep the transaction the commit of which
has failed. The only thing, you can do with it is to abort it.

Relational databases behave in the same way: when the commit
fails (usually due to lock contention/dealock avoidance), the
transaction is implicitly aborted (to get the blocked resources freed).

I can see only one reason why to keep the failed transaction in tact:
in order to analyse it (which objects have been registered).
But, up to now, I did not yet meet any occasion where I really had
wanted that.

-- 
Dieter