Proposal: WebDAV and transactions - stepping back to requirements

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