W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: One lock per resource per person?

From: <ccjason@us.ibm.com>
Date: Fri, 15 Oct 1999 16:34:33 -0400
To: jamsden@us.ibm.com
cc: w3c-dist-auth@w3.org
Message-ID: <8525680B.0070A2D1.00@D51MTA03.pok.ibm.com>

A principal can only have one lock on a resource. If the lock is exclusive, then
there can only be one. If the lock is shared, then getting another shared lock
would not give owning principal any further capability. I don't have the spec if
front of me, but I believe this is spelled out.
I believe the spec implies what you say.  Feel free to double check that.  It
would be useful to know where it says/implies that... but I'm also suggesting
a change if that's what the spec says... not just asking what the spec says.

It does give new capability though.  It's the right hand/left hand thing.  Two
independent client tools using the same ID.  They both want to block writes to
(coincidentally) the same resource.  Sure the second locker could do a lock
discovery... but then they'd also have to work out who is the last one that
wants to release the the lock.  Remember... these are independent tools.  It
won't work without some cooperation.  And having multiple locks on the same
resource solves this problem neatly.

As my note says, it looks like the spec already supports this for inherited
shared lock to some degree.  If so, the issue then becomes... "Can the two
shared locks owned by the same entity be rooted at the same resource?"  I'm
suggesting they should.

Received on Friday, 15 October 1999 16:30:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:18 UTC