Second Postion Paper - Atomicity in DAV

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