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