On Jan 7, 2008, at 9:35 AM, Christian Theune wrote:
Hi,
Am Montag, den 07.01.2008, 07:29 -0500 schrieb Jim Fulton:
On Jan 7, 2008, at 5:58 AM, Christian Theune wrote:
Hi,
I was wondering whether it might be reasonabl to let a ConflictError
always doom a transaction.
It already does afaik,
Hmm. It doesn't seem to, but at least committing a second time raises
the same conflict error again.
I was referring to read conflicts. Dooming write conflicts isn't
necessary because the data remains in conflict, as you noticed.
If you look at things like `tal:on-error` then those errors can be
accidentally swallowed and still have the transaction commit. If the
transaction was doomed then those requests would provide a real
error
because the transaction couldn't be committed although the publisher
tries.
Thoughts?
(I think this is sort of a more zodbish than zopeish question, so
I'm
posting it here.)
I'm 99% sure that conflict errors already doom transactions. Note
that the scenario you describe should not occur in any case due to
mvcc unless the invoked code does a commit.
You're right.
The idea of making conflicts doom the transaction was to avoid
accidental subsequent commits.
The whole doom mechanism was added to deal with read conflicts.
Turns out this already happens because
the conflict stays.
(The thought was inspired by application-level exceptions that express
referential integrity problems and we're using doom there.)
I'd be interested in what your motivation of making ConflictErrors
doom
the transaction is as my motivation seems to be invalid.
In general, a conflict error should prevent a commit unless it is
dealt with. I think my motivation and yours are the same. The doom
mechanism is meant to deal with read conflicts. It isn't needed for
write conflicts.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
