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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

_______________________________________________
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

Reply via email to