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

[Shane Hathaway]

Toby Dickenson wrote:
> On Tuesday 26 November 2002 9:17 pm, Jeremy Hylton wrote:
> 
> 
>>- Can some form of locking be correctly and fully implemented at the
>>  application layer?  Is there anything about a locking mechanism that
>>  complements optimism that must be implemented in the database?
> 
> 
> Yes. I dont think Shane was suggesting using an application-level lock instead 
> of zodb versions. The two approaches are complementary, and need to be used 
> simultaneously for best effect.
> 
> The application-level queue is there to avoid version lock errors.
> 
> Versions are there to guarantee consistency (by raising version lock errors) 
> if something neglects to use the queue.

Well, I was indeed suggesting that ZODB versions might not be necessary.

But you described an interesting approach.  The application could catch 
version lock errors and send the catalog updates to a (non-versioned) 
queue instead.  I like that idea.

However, in that case, the original problem remains: in order to 
guarantee that the long-running transaction succeeds, the sysadmin has 
to individually lock all of the objects in the catalog.  Otherwise, in 
the middle of the sysadmin's work, a user may make changes to the 
catalog without touching any of the objects that haven't yet been 
versioned, resulting in a conflict if the sysadmin tries to change the 
same objects.

One solution is to use an application-level lock that only gets acquired 
for long-running transactions.  Before making changes, the catalog is 
expected to check whether this lock is set.  If it is set, it should 
kindly put items in the queue instead of changing the catalog.  If the 
problem is solved that way, version locks don't seem to help any.  Or do 
they?

> One thing that makes me nervous of versions is that, in Zope at least, they 
> can get created implicitly. There is no explicit 'create a version' 
> operation.

Yes, that is a terrible misfeature.

Shane