[Zope] Conflict Errors

[Chris McDonough]

Damn, this is an excellent description.  I'm gonna go add it to the 
developer's guide.

Toby Dickenson wrote:
> On Thu, 01 Nov 2001 01:00:14 -0500, Chris McDonough
> <chrism@digicool.com> wrote:
> 
> 
>>Yeah, well... yeah.  (Staring at shoes)... conflicts can also happen 
>>on.. reads.  Yes.  Read conflicts, they're called.  This happens in the 
>>setstate method of Connection.py.  There's some explanation for this 
>>that has to do with consistency of data but I don't know it; at least I 
>>dont know it well enough to explain it competently.
>>
> 
> Zope loads objects from their persistent store into memory when they
> are first accessed. So if you have a transaction that touches several
> objects, you will be loading those objects gradually throughout the
> transaction.
> 
> (unless they are already in memory anyway; lets assume they are not)
> 
> Consider one of the last objects to be loaded..... the question is:
> what happens if that object has been modified in a different thread
> since the start of this current transaction?
> 
> Ideally, Zope would load the original state of the object. That is,
> the state that was current at the time when this transaction started.
> However, this capability has not yet been developed. When it does read
> conflicts will not happen.
> 
> Another option would be to load the new state of that object. This is
> what the first revision of ZODB did, and it is bad because it leads to
> inconsistencies. Our transaction sees some, but not all of the changes
> made in a different transaction. There are some objects for which this
> isnt a problem; I think the LowConflictConnection class that Chris
> referred to can allow you to exploit this.
> 
> 
> 
> 
> Toby Dickenson
> tdickenson@geminidataloggers.com
> 


-- 
Chris McDonough                    Zope Corporation
http://www.zope.org             http://www.zope.com
"Killing hundreds of birds with thousands of stones"