- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Tue, 04 May 1999 14:55:17 -0400
- To: w3c-dist-auth@w3.org
Sorry if this has already been discussed but it seems to me that exclusive locks can be replicated using the refresh mechanism and hence aren't really guaranteed to be exclusive but rather sort of shared. Look at this example: - While working in my office I get a lock on a resource and start edit it. I suddenly have to run home so I save the edits but don't want to release the lock as I don't want other people to start editing the document. - Later on at home I continue editing the document but the document is still locked by me at work. However, I can discover the identity of the lock using a PROPFIND and while I can not relock the resource it seems that I can do a refresh on it which again seems to give me a copy of the lock at home. - I then edit at home and save the edits back but don't release the lock as again, I don't want other people to start editing it. I now have two copies of the exclusive lock with two different revisions of the document. As there is no apparent link between a lock token and a specific revision of the resource (UUIDs at least don't do this), the lock can't help me detect the lost update problem and I may loose edits. In any case, the lock is no longer exclusive. If this is true then it seems to me that one of the following solutions must be put in place: - tie the lock to the content of the resource in a unique way, - don't allow refreshing a shared lock, or - require that strong etags always are used together with locks Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk
Received on Tuesday, 4 May 1999 14:55:19 UTC