- From: Dennis E. Hamilton <dennis.hamilton@acm.org>
- Date: Fri, 13 Sep 2002 08:31:00 -0700
- To: <w3c-dist-auth@w3.org>
- Cc: "Babich, Alan" <ABabich@filenet.com>, "Roy T. Fielding" <fielding@apache.org>, "Jim Whitehead" <ejw@cse.ucsc.edu>, "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>, "'B. Shadgar'" <shadgar@cs.bris.ac.uk>, "Pill, Juergen" <Juergen.Pill@softwareag.com>
1. WHAT ARE THE REQUIREMENTS? It seems to me that the conversation on transactions is looking at different approaches to something that might be transactions and comparing those possible implementations without being sure that we are talking about the same concept for transactions and whatever the requirements might be in the context of WebDAV. I think it is very valuable at this point to stand back and investigate exactly what is required for transactions and what the constraints on their support would be for WebDAV. Here are some things that I noticed in thinking about this. Subject-matter experts would have something more useful to say: 2. WHAT ARE TRANSACTIONS? I think there needs to be agreement at this level. This is a key point of understanding before being able to proceed. Here is what occurs to me: 2.1 Transaction protection is a way to assure that a persistent store (database, etc... ) never presents an unrecognized inconsistent state, and the failure modes always revert to a consistent state. My understanding is that in the general case the notion of consistency is beyond the consistency of the store abstraction. It is there to support the consistency required by the application in which the store is used instrumentally. The consistency at the granularity of the store abstractions (e.g., WebDAV with locking) is assumed to be handled already. Now we are talking about consistency in coordinated use of a store for satisfying requirements that are operable at a different level of abstraction. 2.2 Put simply and quite generally, a transaction looks atomic to everyone but the originating process, and it looks atomic to the originating process outside of the critical section of the transactioned process. And the effect is to achieve a consistent state to all observers outside of critical sections (the one place where rules are broken in order to be implemented). And it is requirements of the implemented application that govern what those consistency/atomicity conditions are and what their satisfaction is. 2.3 Transaction Processing models are highly abstracted, because we are constrained from knowing all the particular ways that transactions may be required in securing the consistent operation of an application. So support is utilitarian. There will be limitations on the scope of support, and understanding what those are and what the cost of going beyond it (as well as the economy of staying within it) needs to be understood. 3. REQUIREMENTS FOR TRANSACTION-PROCESSING SUPPORT Key things that I think have to be agreed around requirements for transactions are. I am not that great in thinking at the requirements level, so if these don't read like requirements bear with me. Consider instead what might be the requirement behind quasi-requirements like these: 3.1. What is the required atomic appearance of consistency outside of critical (transaction-protected processing) sections? (Express as a principle and what people are to get out of it, not so much as a given solution.) 3.2. What is the required appearance of consistency within critical sections? (E.g., do changes to an underlying store appear to have taken place just as they would if transaction-protection were not requested?) 3.3. What is the ability to integrate in a transaction regime that extends beyond the operation of a single WebDAV service? Related to scope of support (3.5) and 3.4. The unobtrusiveness of transaction support in the expression of transaction-protected processes (e.g., that there be little or no difference beyond what it takes to signify that an operation is protected under an identified transaction) - only expressed at the level that doesn't foretell an implementation or protocol approach 3.5. What is the scope of required consistency support (the place where use-cases might help the most). 4. CONSTRAINTS There are constraints that will apply to the acceptable introduction of transaction-processing support in the WebDAV protocol. These limit the solution space available for responding to requirements. (Again, I am not that practiced at differentiating between constraints and requirements. I recognize value in doing so.) Here are some candidates: 4.1. Actually using an (existing) transaction model at all. I notice in (3) I am presuming that transaction-protection techniques are required. I do think that is a given, because it is an integrative requirement (integrating with available rather-standard mechanisms, integrating from the standpoint of the knowledge and experience required to develop and validate applications). But the requirement for that or the constraint of that needs to be surfaced. 4.1. Supporting provisions must honor the STEP model and the spirit of HTTP to no lesser degree than WebDAV already does (that is, simply tunneling another protocol wouldn't count) 4.2. If there is a way to provide a scaled-down, high-value case, it must be convincing and not merely intended that it does scale. (I don't know how you do that without demonstrating a full solution, but who knows ... .) 4.3. And scaling between non-support and (degrees of) support. Like, reusing already-defined methods and supplementing their request bodies or something like that, wherever possible. Something about failure cases in this area, along with conditions on use of HTTP and WebDAV error status, etc. -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Thursday, September 12, 2002 12:58 To: Gary Cowan; w3c-dist-auth@w3.org Subject: RE: Proposal: WebDAV and transactions > Well I suppose, but isn't this what wrapping updates with a > Lock/Unlock pair is intended to accomplish. I have nothing > against transactions, I just don't have any need for them > spanning multiple WebDAV methods. Yet:) Lock/unlock doesn't give you rollback capability. Even though you're the only person who can write to a resource during a lock, it still may be the case that you're unable to complete the PROPPATCH part of a PUT/PROPPATCH pair. The TCP connection may go down, the server may go down, you may be exceeding your quota, etc. Now, if the total number of use cases is relatively small, it probably makes more sense to create new methods explicitly for these use cases, instead of a general purpose transaction mechanism. - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding Sent: Thursday, September 12, 2002 07:01 To: Babich, Alan Cc: w3c-dist-auth@w3.org Subject: Re: Proposal: WebDAV and transactions [ ... ] That's not how I described transactions. I said that the requests are collected on the server and only applied when the commit message is received. If the state has changed such that the methods are no longer applicable, then the method transaction will fail on commit. ....Roy -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan Sent: Monday, September 02, 2002 13:59 To: 'B. Shadgar'; Pill, Juergen; w3c-dist-auth@w3.org Subject: RE: Proposal: WebDAV and transactions One thing you do NOT want under any circumstances are begin-transaction, end-transaction, and abort-transaction methods. [ ... ]
Received on Friday, 13 September 2002 11:32:22 UTC