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

[Shane Hathaway]

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.
> 
> 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.

Well, now that you call it a "lock" it occurs to me that this feature 
might solve the catalog reindex problem.  Currently, if a sysadmin tries 
to reindex a lot of objects at once, and someone changes an object in 
the catalog, the sysadmin loses.  We really want the sysadmin to win. 
So you're saying that if this feature had a different name, perhaps we'd 
be more inclined to use it, but for different purposes than originally 
intended.

However, in the case of the catalog it would be simpler and more 
efficient to put the locking in the application logic.  The catalog 
would have a "lock" flag that gets checked before making any changes. 
The sysadmin locks the catalog at the beginnging of a long-running 
operation.  During this time, catalog updates get queued instead of 
being applied immediately.  This would work really well, I think.

So I'm inclined to believe that locking, as well as versioning, is 
better handled by the application than ZODB.  Can you think of any 
specific uses where ZODB locks would work better than application locks?

Shane