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: Mon, 18 Oct 1999 20:57:57 -0400
To: w3c-dist-auth@w3.org
Message-ID: <8525680F.0004EFDA.00@D51MTA03.pok.ibm.com>

This original question seems to have gotten lost in a tangent.  I'd appreciate
hearing more voices on this original issue which now is...

"Can the two
shared locks owned by the same principal be rooted at the same resource?"

---------------------------------------------------------
To:  w3c-dist-auth@w3.org
Subject:  Re: One lock per resource per person?




  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.

J.
Received on Monday, 18 October 1999 20:54:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:52 GMT