Re: Locking in a versioning server

ccjason@us.ibm.com
Tue, 19 Oct 1999 16:46:25 -0400 

From: ccjason@us.ibm.com
To: jamsden@us.ibm.com
cc: ietf-dav-versioning@w3.org
Message-ID: <8525680F.0073EE23.00@D51MTA03.pok.ibm.com>
Date: Tue, 19 Oct 1999 16:46:25 -0400
Subject: Re: Locking in a versioning server




    Maybe you're forced to do what you just said... but shouldn't a lock on a
    versioned resource just apply within the workspace?  Or is there some other
    mechanism to protect who users of the workspace from stepping on each other
    without affecting users outside the workspace?
  <jra>
  Versioned resources are independent of workspaces. Workspaces only effect
  working resources and revision selection.
  </jra>

Okay.  Then is there another mechanism to achieve this?  It seems like a
reasonable request by a client to be able to do this.  Below it looks like
they could use checkout and then do the lock.  But that certainly would make
a depth lock tedious if preceeded by lots of check outs.  And then many of
those would have to be followed by checkins or uncheckouts.  And in the case
of shared locks, those clients would have to cooperate to coordinate the
uncheckouts in an agreed fashion... unless we add something to the server to
automate all this for the client.

Caveat: I don't expect people to use shared write locks.  I do expect them
to use shared read locks when those are defined.

Issue: But shared read locks also have a race condition if the lock has to
be preceeded by a checkout to restrict the lock to the workspace.  That
race condition could be made manageable, but the spec writers have to
keep an eye on that issue to insure that the client can detect when the
race condition has bitten him.  (Can the client detect if what he
actually locked is NOT a working resource?)  You may already have the
mechanism in place... I'm not familiar enough with the versioning spec
to know.

Question: If you lock a working resource and someone checks it in, what
happens?


     Locking an activity prevents any principal other than the owner of the lock
     from
     making any further changes in the context of that activity. That is, it is
     not
     possible to checkout a resource using a locked activity.

    Sanity check.  Activities are resources, right?  Activities can be created
(and
    destroyed?) but the activity itself can never be directly modified by client
    methods like PROPPATCH, right?    (Sorry if it's a dumb question.  I only
have
    the spec to go by.)  It looks like required-activites might be user
    modifiable... but then again, perhaps it's only set when the activity is
    created.
  <jra>
  Activities are resources created with MKRESOURCE. They have properties that
are
  effected as the result of checking things out and in in the context of the
  activity. They provide information required for merging. They label segments
of
  the line of descent. They can have dependent activities (which are implicitly
  included in workspace and merging operations). And they may have properties
that
  user can change with PROPPATCH.
  </jra>
Thanks for the info. -- If that resource can take a PROPPATCH method, then you
probably should indicate if a write lock protects against that.  You don't
actually mention any protection for the activity resource itself.


  <jra>
  Locking is not necessary to avoid update conflicts in different workspaces.
Each
  workspace will select a different working resource. Locking working resources
is
  only useful if two or more principles are using the SAME workspace. This may
  often be the case when the default workspace is used.
  </jra>

Right... lock prevents two or more principals (we must work out the spelling of
that
word :-)) within the same workspace.  That's a good thing.  But the definition
you
provided makes it sound like it locks the resource itself which you've also just
said is not specific to a workspace. So although the intent of the lock may have
been local to the workspace, it sounds like the spec'd affect stretches outside
the
workspace.  That's what I'm refering to.

Now apparently if the resource that is locked is actually a working resource,
then
the lock essentially remains local to the workspace.  Super.  But it does make
depth locks tedious though without a helping hand from the server.

Or perhaps I'm just all mixed up.  :-)