[Zope3-dev] Re: [ZODB-Dev] ZODB4 project plan

[Casey Duncan]

On Tuesday 26 November 2002 03:58 pm, Shane Hathaway wrote:
> Jeremy Hylton wrote:
> > The counter-argument is that a version, while poorly named, provides
> > the only mechanism for locking objects to guarantee progress for a
> > long-running operation.  Without versions, the longer an operation
> > takes the more likely it is to hit a ConflictError.  With versions, a
> > long-running operation can be structured into two phases.  The first
> > phase copies all the objects into the version.  The second phase does
> > the application logic (whatever it is).  When the second phase
> > finishes, it commits the version.  If the second phase fails, it
> > aborts the version.
> >=20
> > I think that versions add complexity and are poorly named, but are
> > a valuable feature.  I'd be in favor of changing the feature's name -=
-
> > perhaps calling it a lock instead of a version -- and rethinking how
> > it is exposed in the various ZODB APIs.
>=20
> Well, now that you call it a "lock" it occurs to me that this feature=20
> might solve the catalog reindex problem.  Currently, if a sysadmin trie=
s=20
> to reindex a lot of objects at once, and someone changes an object in=20
> the catalog, the sysadmin loses.  We really want the sysadmin to win.=20
> So you're saying that if this feature had a different name, perhaps we'=
d=20
> be more inclined to use it, but for different purposes than originally=20
> intended.
>=20
> However, in the case of the catalog it would be simpler and more=20
> efficient to put the locking in the application logic.  The catalog=20
> would have a "lock" flag that gets checked before making any changes.=20
> The sysadmin locks the catalog at the beginnging of a long-running=20
> operation.  During this time, catalog updates get queued instead of=20
> being applied immediately.  This would work really well, I think.

If you applied this in reverse, then "versions" might actually be more us=
eful.=20
That is, Changes to the catalog from inside a version/lock would be queue=
d=20
(in an object that only exists in the version). Then when the version is=20
saved, the queue is emptied and the objects are cataloged.

Another thought: Would it be possible to develop "locks" such that some=20
objects might have "version lock conflict resolution" such that they can=20
handle being modified in two different versions at once?

I know that could be a mind bender, but it would be a powerful remedy for=
=20
ZCatalog concurrency if we applied it to BTrees. And how different would =
it=20
need to be from current conflict resolution?

-Casey