[ZODB-Dev] ConflictError vs Doom

[Jim Fulton]

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