Re: [ZODB-Dev] ConflictError vs Doom
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, 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. 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
Re: [ZODB-Dev] ConflictError vs Doom
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 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
Re: [ZODB-Dev] ConflictError vs Doom
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
Re: [ZODB-Dev] ConflictError vs Doom
On Jan 7, 2008, at 10:04 AM, Christian Theune wrote: Am Montag, den 07.01.2008, 09:48 -0500 schrieb Jim Fulton: 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. Grepping through the ZODB for doom( I couldn't spot a place where read conflicts would automatically doom the transaction. Looking myself, I see that ZODB doesn't doom the transaction but prevents commit by raising a read conflict if the transaction is committed. I wonder if anyone is using the transaction doom mechanism. If not, we should remove it. 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
