[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released
Shane Hathaway
shane at hathawaymix.org
Sat Sep 11 17:32:06 EDT 2004
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
More information about the ZODB-Dev
mailing list