- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 17 Mar 1997 17:33:12 -0800
- To: w3c-dist-auth@w3.org
There have been a number of cases presented where atomicity over a group of operations has been desirable. The use of atomicity has been to prevent inconsistencies in state. For example, one may wish to first copy new files into place while checking if certain links are still active. If the file update and link checking turn out correctly then one would like to update some more files with the new file and link information. A WRAP method can not support this scenario because it does not support receiving responses before continuing with the execution of methods, it is all or nothing. So if the link checking and file copying succeeds, someone may still show up before the files are updated with the new information and make changes. Locking all the resources involved is not enough because the client may loose their connection while in the middle of performing the updates and the system will be left in an inconsistent state. The previous scenarios, however, are safely dealt with through a combination of atomic checkout and the UNCHECKOUT method. The checkouts prevent alteration to the resources while the system is being updated and in the worst case, if the system is left in an inconsistent state, UNCHECKOUT can be used to restore it. The problem with UNCHECKOUT is that it is rather ham fisted. Either all changes are accepted or lost. As I'm sure the reader has surmised, this path of investigation is leading toward a full blown transactioning system. I believe it would be a mistake for DAV to go down that path. DAV already has a sufficient number of complex issues to keep it busy for quite some time. My recommendation is that we deal with the situation as follows: 1. We deal with the issue of atomic checkouts by requiring that the user create a collection containing all the files to be checked-out. Through the use of hard links (currently implemented with ADDRESOURCE, but I will be proposing a different mechanism using links) any arbitrary numbers of resources can be grouped together. The user will then lock the collection using the recursive header and include the atomic header, which is defined in my position paper on structure and collections. In essence, however, the atomic header specifies that if an operation effects multiple resources then all requested actions must succeed or the entire request must fail. 2. Finally, I propose that we introduce an UNCHECKOUT method to allow for clean up. The semantics of the UNCHECKOUT method are defined in my position paper on versioning. However, in summary, UNCHECKOUT only applies to resources that are exclusively checked out and causes the resource to roll back to the state it was in before the principal checked the resource out. Yaron
Received on Monday, 17 March 1997 20:34:38 UTC