W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

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

From: Eric Sedlar <esedlar@us.oracle.com>
Date: Fri, 14 Jan 2000 01:58:38 -0800
Message-ID: <002101bf5e75$ee294590$9a114498@us.oracle.com>
To: <ccjason@us.ibm.com>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
This is what is supposed to happen when you lock a collection--you lock all
of the names within it, probably given that you are going to do a
reorganization.  For you to demonstrate that this is a problem, give a
scenario where a versioning-unaware application is going to lock a


----- Original Message -----
From: <ccjason@us.ibm.com>
To: "Eric Sedlar" <esedlar@us.oracle.com>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>;
Sent: Thursday, January 13, 2000 2:32 PM
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

> Ah... Eric's note brings up another possibility.  It might be a red
> herring, but as Geoff's
> proposal is currently written (and Eric's too I think) it still is a
> possibly unexpected behavior.
> User B  locks /a/b/ exclusively.
> User D tries to do a shared lock on /a/b/c/d.html but fails because in the
> proposal that
> will also create a lock (or will it?) on /a/b/ which already has an
> exclusive lock on it.
> I'm not saying this is good or bad.  I'm just pointing it out as what
> sounds like a difference
> in the recent proposals relative to what we were proposing a month or more
> ago.
> Jason.
Received on Friday, 14 January 2000 04:59:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC