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

Shane Hathaway shane@zope.com
Tue, 26 Nov 2002 16:34:36 -0500


Jeremy Hylton wrote:
>>>>>>"SH" == Shane Hathaway <shane@zope.com> writes:
>>>>>
> 
>   SH> However, in the case of the catalog it would be simpler and more
>   SH> efficient to put the locking in the application logic.  The
>   SH> catalog would have a "lock" flag that gets checked before making
>   SH> any changes.  The sysadmin locks the catalog at the beginnging
>   SH> of a long-running operation.  During this time, catalog updates
>   SH> get queued instead of being applied immediately.  This would
>   SH> work really well, I think.
> 
> If the application is reponsible for locking, then you must agree to
> do the locking everywhere in your application.  If there is an object
> that can be locked, then every client of the object must know about
> the locking protocol and implement it correctly.  If the objects are
> fairly dumb, it seems plausible that someone would write a new script
> that modifies an object while forgetting to interact through the
> locking API defined by the application.

True, but ZODB already has a "hole" that I would classify about the same 
way: scripts that are meant to only read the database can accidentally 
change the database.  It's very easy and this is a real concern in some 
environments.  But in practice, we rarely see anyone make that mistake. 
  It's easier to fix individual infractions than try to prevent it from 
ever happening.

> I guess some questions to answer are: 
> 
> - 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?

Well, I suppose __setattr__ hooks could imitate database locks, but I 
wouldn't recommend that. :-)

> - Would the locking mechanism be significantly more efficient or
>   robust if it was implemented in the database?

Since the locking is per-object, locking in the database is potentially 
much less efficient than application-level locking.  To lock a tree of 
objects, you have to visit the entire tree just to discover what OIDs to 
lock.

Shane