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

[Jeremy Hylton]

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

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?

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

Jeremy