[Zope] Conflict Errors

[Toby Dickenson]

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=20
>on.. reads.  Yes.  Read conflicts, they're called.  This happens in the=20
>setstate method of Connection.py.  There's some explanation for this=20
>that has to do with consistency of data but I don't know it; at least I=20
>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