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

[Shane Hathaway]

On Thursday 09 September 2004 14:01 pm, Tim Peters wrote:
> [Dieter Maurer]
> > 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).
>
> Good for them <wink>.

Not quite: In PostgreSQL, some (maybe most?) errors force you to explicitly 
roll back before you can do much of anything again.  The one case I know of 
is that if you try to access a nonexistent table, PostgreSQL refuses queries 
until you roll back.  It apparently assumes that the program is broken and 
deserves to lose, which I find reasonable.  I don't know any more details 
since I happily complied right away. :-)

> > 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.
>
> It's not trying to keep the transaction intact, it's trying to prevent
> another commit() from succeeding, until the code trying to do that next
> commit() explicitly acknowledges that a prior commit() failed (via invoking
> abort() or begin(), which unambiguously ask for a new transaction).
>
> Maybe nobody *really* wants that.  Three people +1'ed the idea before your
> response, so my best guess is that they do want that.  I don't know what
> Shane wants (AFAICT, he kept asking for behavior that ZODB already
> implements -- it's already the case that ZODB will not allow a transaction
> to commit if that transaction suffered a ReadConflictError).

Email can be a painful mechanism of expression. :-/

What I want is for transactions to be completely explicit.  I want one piece 
of code to govern transactions while the rest of the program is subject to 
the code that controls transactions.  If transactions begin implicitly, the 
transaction control code doesn't have the power it should have and knowledge 
of transactions spreads all over the place.  "except ConflictError:" clauses 
are the most visible manifestation of this fault.

Shane