On Fri, 2003-09-12 at 07:34, Chris Withers wrote: > Tim Peters wrote: > > "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...
Nope. The 'ZODB3-3_1-branch' has retired; all future "ZODB3 3.1.x" work will take place on the 'Zope-2_6-branch'. MVCC, however, is new feature work, and will take place on the 3.2 branch (which may be the Zope-2_7-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? Some applications will have no downside at all; for instance, requests that will do no writing the the database are pure wins for MVCC (e.g., long-running "report" requests). Requests that write to the database on the basis of stale-but-consistent data *may* still be OK, but that will need to be a policy set by the application. Tres. -- =============================================================== Tres Seaver [EMAIL PROTECTED] Zope Corporation "Zope Dealers" http://www.zope.com _______________________________________________ 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 )
