[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Michael Dunstan]

On 8/09/2004, at 12:53 PM, Tim Peters wrote:

> [Florent Guillaume]
>> Actually the ones I'm thinking about have been added to code that
>> originally did:
>>     try:
>>         ...stuff...
>>     except:
>>         LOG('an error happened: %s' % sys.exc_info())
>>         # continue anyway as we "shouldn't fail"
>>         # or we "want to return a default value if we fail"
>>     ...rest...
>>
>> This happened for instance in manage_beforeDelete, _delObject or even
>> restrictedTraverse.
>>
>> This was changed to:
>>     try:
>>         ...stuff...
>>     except ConflictError:
>>         raise
>>     except:
>>         LOG('an error happened: %s' % sys.exc_info())
>>         # continue anyway as we "shouldn't fail"
>>         # or we "want to return a default value if we fail"
>>     ...rest...
>>
>> To make sure we didn't inadvertently catch something that could make 
>> the
>> database inconsistent.
>
> I don't know of a scenario in current ZODB wherein catching something 
> can
> make a database inconsistent.  I understand there are persistent 
> rumors that
> it can happen, but requests for a specific case have gone unanswered.  
> So I
> suspect something else is at work, and "catching exceptions" is a 
> convenient
> scapegoat in the absence of understanding.  Perhaps these are just 
> stale
> rumors, left over from earlier versions of ZODB.
>
> There's generally no *point* to continuing a transaction once it has
> experienced a ConflictError -- current ZODB intends never to let a
> transaction commit if it experienced a ReadConflictError in its 
> lifetime.
> So as soon as you see one, you may as well give on the transaction 
> ASAP, and
> retry it.  But there's still no general way to know exactly what "ASAP"
> *means* from code snippets -- it depends on the full context, and may 
> mean
> different things in different contexts.

Yup - avoiding silently swallowing of a ConflictError is an 
optimisation for most cases. However there was a recent suggestion that 
swallowing such exceptions thrown by from within a call to commit() 
would be non ideal. I'm waving my hands here a bit too much here. I 
should just point to the reference...

http://mail.zope.org/pipermail/zope-dev/2004-July/023418.html

michael