[ZODB-Dev] ConflictError vs Doom

Christian Theune ct at gocept.com
Mon Jan 7 09:35:58 EST 2008


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.

> > 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. 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.

Christian

-- 
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20080107/be63ca8d/attachment.bin


More information about the ZODB-Dev mailing list