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

Re: One lock per resource per person?

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 1 Nov 1999 19:24:30 -0500
Message-Id: <9911020024.AA28876@tantalum>
To: w3c-dist-auth@w3.org
   From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>

   <ck/> Using SCC systems today, I can
   create multiple shared locks against the same resource.  In
   general you can do this by "checking it out" multiple times, but
   the basic notion is that I may be engaged in parallel activities
   at my client even though I am the same principal.

   <gmc/> It's very important to distinguish "multiple checkouts" from
   "shared locks".  Multiple checkouts are safe and do not suffer from
   any lost update problem.  Shared write locks are not safe, and you are
   susceptible to getting your update's trashed by anyone else that
   shares that lock.

   <ck/> But my client may use shared locks to coordinate updates.  The 
   client app doesn't recognize principals...

<gmc/> Whether or not the client recognizes principals doesn't seem to
affect the issue in question.  My point was that a checkout gives a
client a new resource (a "working resource") that is distinct from any
other parallel checkout, so you are guaranteed that your updates will
not overwrite those of another client that has done a parallel
checkout.  In contrast, an update to a resource with a shared write
lock can easily overwrite updates from another client that has a
parallel shared lock.  Perhaps I misunderstand what you have in mind
when you say that your client may use shared locks to coordinate
updates?

Cheers,
Geoff
Received on Monday, 1 November 1999 19:24:36 GMT

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