Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

Why are you still allowing the "lock-null" approach (now renamed as the
dummy namespace lock)?  I thought one of the goals of GULP was to get rid of
that horrible concept.

--Eric

----- Original Message -----
From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Friday, January 14, 2000 5:52 AM
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


>    From: "Eric Sedlar" <esedlar@us.oracle.com>
>
>    You want to avoid having name and resource locks as separate entities,
so
>    you basically say that a name lock (as in my proposal) locks the
resource it
>    is bound to, if any.
>
> Yes.
>
>    If the lock is exclusive, you can't lock any other
>    name applied to that resource.  For example, if I have /a/foo.html and
>    /b/foo.html both identifying the same resource, if I exclusive lock
>    /a/foo.html, I can't protect the name "/b/foo.html" since I can't lock
it.
>
> You cannot apply an exclusive lock of the same type to /b/foo.html,
> but if you just wanted to protect the name /b/foo.html, you could
> request a lock of a different type on /b/foo.html (exclusivity is
> lock-type specific).
>
> Alternatively, if your server only supports one kind of lock type, you
> could lock /b/foo.html/dummy-namespace-lock, which would have a similar
effect
> (and does not conflict with the exclusive lock already on /b/foo.html.
>
>    Since the LOCK protocol request currently doesn't distinguish between
name
>    and resource locks, you couldn't lock /b/foo.html anyway (which is why
you
>    are ok with the restriction above), since the protocol request would
try to
>    lock the resource identified by /b/foo.html as well as the name.
>
> GULP does not distinguish between "locking the resource" and "locking the
> name", although it does distinguish "a lock whose target is X/." and
> "a lock whose target is ."
>
>    However, it does seem like there will be reasons to protect the
namespace in
>    this way, and I think you are paying a price for reducing the number of
>    locks.
>
> If you wanted to introduce a "namespace lock", you could do so with the
> standard lock extension mechanism (i.e. allow both "write" and "namespace"
> locks), but that is different from saying there are two different kinds
> of locks in the underlying locking model.
>
>    > - If an exclusive lock identifies a resource, no other lock of that
type
>    can
>    > identify that resource.
>
> Note that I have modified this statement to read:
>
> - If a resource has an exclusive lock, that resource cannot be locked
> with another locks with the same type and target but a different
> token.
>
> This ties the semantics to the lock state of a single resource, rather
> than using the vaguer concept of "the resource identified by a lock".
>
>    Here's a scenario: it seems like if application A has an exclusive lock
on
>    /a/foo.html (say because it is planning on updating the resource to
create a
>    new version, and it wants to prevent lost updates) and application B
wants
>    to only read /b/foo.html and protect the namespace so that it can find
it
>    again later, application B cannot create a shared lock on /b/foo.html,
>    correct?
>
> They can add a lock with a different type from the exclusive lock,
> or if there are no other lock types available, they can do the "dummy
lock"
> approach of locking "/b/foo.html/dummy-namespace-lock".
>
>    The problem is that application A will not actually update the
>    resource that app B is working with--it will just create a new
revision.
>    (Although this may affect the revision selected by app B).  Is this an
issue
>    your versioned locks deal with?
>
> Versioning is (of course :-) somewhat trickier.  A lock in the presence of
> versioning isn't so much concerned with locking the state of a resource
> (the majority of the visible resources will be checked-in revisions, and
> couldn't be modified even if you wanted to), but rather is concerned with
> locking the target selection (so that you don't end up effectively getting
> a namespace or state change because new revisions are selected).  This
> issue (as you suggest) is addressed with the "revision selection freezing"
> I've proposed for the versioning protocol.
>
> Cheers,
> Geoff
>
>

Received on Friday, 14 January 2000 13:36:31 UTC