"Multiversion concurrency control" (MVCC for short) is the next step. If no other crises intervene, Jeremy and I will start implementing that on the ZODB3 3.2 branch (most likely that branch -- can't swear to it) soon (ditto).
From Jeremy's recent notes, I think it'll be the Zope 2.6 branch...
You can google on the phrase to get a ton of more-or-less abstract overviews of the concept. The short course in ZODB is that, when MVCC is in effect, a read will return the state of the object as of the time the current transaction began, even if the object has subsequently been modified by some other transaction.
Sounds great :-) If you need any implementations testing, do let me know!
The overriding concern in all schemes is that you don't see inconsistent data.
Yep.
The current ReadConflictError prevents you from seeing inconsistent
data by preventing you from loading objects that have changed since your
current transaction began.
Indeed, butthat could eb a lot of things, and often in situations where ti wouldn't matter, as long as the data is consistent...
MVCC prevents it by (possibly) delivering non-current object states. I don't think either can be viewed as a pure win. The ways in which ReadConflictError loses are obvious to people here because they've experienced them. The ways in which MVCC loses will become obvious later <0.9 wink>.
Any ideas what they'll be yet?
Chris
_______________________________________________
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 )
