Subject: RE: Proposal: WebDAV and transactions

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 12 Sep 2002 16:20:06 -0400

The Lock/Unlock doesn't give you the "rollback" functionality 
(i.e. the client has to remember the old values, and live long
enough to restore them if the later updates fail).

But it would be interesting to investigate whether the
DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
of the benefits of transactions (a non-versioning server would
only keep the most recently checked in "version" of a resource).
You would create an "activity" for a given transaction,
make your changes, and then CHECKIN the activity to commit 
all the changes, or UNCHECKOUT to roll them back.  

Cheers,
Geoff

-----Original Message-----
From: Gary Cowan [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 3:43 PM
To: 'Jim Whitehead'; [email-masked]
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:)  

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 3:24 PM
To: [email-masked]
Subject: RE: Proposal: WebDAV and transactions

One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; [email-masked]
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; [email-masked]
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: [email-masked]
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> 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>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan

---

From: "Sridhar Erukulla" <[email-masked]>
Date: Thu, 12 Sep 2002 17:26:47 -0400

Naive questions:

What if the old values can't be assigned to some/all of the filed
transaction?

What would an another client see if they query for these properties while
performing the alternative method for a transaction? the old or the new
values? Here the new values should be visible only after all the requests in
the batch are completed, is this something easy to implement?

Sridhar
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Clemm, Geoff
Sent: September 12, 2002 4:20 PM
To: [email-masked]
Subject: RE: Proposal: WebDAV and transactions

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 3:24 PM
To: [email-masked]
Subject: RE: Proposal: WebDAV and transactions

- Jim

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 12 Sep 2002 19:06:11 -0700

This would be ok as long as it is cheap to delete activities on your server.
I suspect this solution wouldn't perform because of the other expectations
folks have of activities (intermediate state is persistent, for example).

--Eric

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 13 Sep 2002 09:36:59 +0200

Am Donnerstag den, 12. September 2002, um 22:20, schrieb Clemm, Geoff:

> [...]

All the use cases mentioned to me for HTTP transactions can be
done with DeltaV. It would be very interesting to hear of an
authoring use case which cannot be satisfied with deltaV
features. And then I would probably try to extend deltav...

If you want to do rdbms-like transactions in WebDAV (with
READ-COMITTED transaction isolation at least), which
are also RESTful, you need to reflect the server state in
the URIs used for the transactions. And if you do that, you'd
sooner or later end up doing what DeltaV has done with
working resource, workspace and activities.

//Stefan