- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 1 Nov 1999 19:24:30 -0500
- 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 UTC