[ZODB-Dev] Re: false write conflicts

[Kapil Thangavelu]

i would say the real issue (as noted by shane somewhere in the archives
;-) is to trigger a persistence change state first rather than relying
on persistence semantics or explict calls to _p_changed after the fact,
because if there are any changes that do not result into a state change
of the object to persistent changed (ie. _p_changed=1) and if the txn is
aborted for whatever reason the object in memory and zodb cache of that
connection is in a possibly inconsistent state. whereas triggering
persistance change state for the object as early as possible will insure
that this does not happen (the object would be evicted from the cache).

hth,

-kapil

On Wed, 2004-03-03 at 09:31, Marius Gedminas wrote:
> On Wed, Mar 03, 2004 at 10:04:15AM +0000, Chris Withers wrote:
> > Marius Gedminas wrote:
> > 
> > >I've seen a recommendation somewhere that it is better to write
> > >
> > >  self.attr[x] = y
> > >  self.attr = self.attr      # notify Persistence that something changed
> > >
> > >than
> > >
> > >  self.attr[x] = y
> > >  self._p_changed = True     # notify Persistence that something changed
> > 
> > Why is that?
> 
> I don't remember.  ;)
> 
> <googles>
> 
> It seems that I misremembered the suggestion -- it is better to use
> _p_changed rather than attribute assignment:
> 
>   http://mail.zope.org/pipermail/zope3-dev/2002-September/002771.html
> 
> And I made another mistake as well: the persistence should be triggered
> *before* modifying self.attr, not after (cf. the same thread).
> 
> Nevertheless there exists code somewhere in the wild that uses the first
> idiom to trigger persistence.  Accidentally mixing this code with a
> __setattr__ wrapper could introduce bugs.  It is probably very unlikely
> in practice, but I like to point out such possibilities.
> 
> Marius Gedminas