> Today you are guaranteed that your transaction reads a consistent initial > state of A and B. That is, there is no chance that you only see half the > changes of a recent transaction that modified both. > > Yes, it is possible for one transaction to modify A and a concurrent > transaction to modify B. This is what Deiter describes as "not safe" in that > zodb-dev thread. IMO, it is only not safe if you are not aware of it. And it > is critical for performance with concurrency - consider these two > transactions occuring on different zeo nodes.
Right, I understand now, thank you. > > In my mind, this is the same thing as > > using a "low conflict connection" (ie. you are essentially "turning off" > > read conflicts, albeit by circumstance rather than by code). > > There is a significant difference. The low conflict connection permits the > possibility of seeing half the changes of a recent transaction that modified > both objects. > > "low conflict connection" is a misleadnig name. The conflicts are still there > - just not reported as exceptions. "low consistency connection" would be more > accurate ;-) Yup. Maybe I should rename it? ;-) So... I'm wondering what the hell I should do. ;-) Obviously I need to deactivate the "low consistency connection" in the default setup. I'm thinking that I also may just need to move the housekeeping duties to a separate scheduled thread that only happens when the system is "not busy" (e.g. when the asyncore poll select timeout is reached maybe) in order to reduce the potential for conflicts. But I'm not sure what else to do, and I still don't understand what is causing the KeyErrors in the storage code. Sigh. - C _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )