RE: Transactions

I don't know what all the fuss is about? The functionality being requested can still be provided without us having to worry about transaction processing. Transaction processing is an implementation detail and not an on the wire issue. We have the same issues with collection copy if there is a failure for some reason. Let's be pragmatic and come-up with a solution which will allow for the locking (copying, moving deleting) of multiple resources with a respone body (XML) which will allow the server to indicate to the client which resources (if any) failed to be locked (copied, deleted, moved ...) and allow the client (respectively the user) to deal with the problem. All that the server has to guarantee in the case of locks is that a lock on multiple resources (whether there was partial failure or not) can be repeated (to attempt lock those resources which failed the first time) and that the granted group lock can be removed without failing if it only partially succeeded.

The resolution of conflicts can be solved by the users in out of band communication. The response body should provide enough information for the user to be able to determine with whom to undertake the out of band communication (I believe someone has already made this point).

Cheers
Dylan

----------
From: 	Fisher Mark[SMTP:FisherM@exch1.indy.tce.com]
Sent: 	Freitag, 25. Juli 1997 16:07
To: 	'Sankar Virdhagriswaran'; 'w3c-dist-auth@w3.org'; 'Jim Whitehead'
Subject: 	Transactions

>>ISSUE 3
>>
>>The current protocol does not allow the clients to inform the servers the
>>current context (also sometimes refered to as the environment in
>>cooperative transaction processing literature). This prevents us from
>>implementing long term, cooperative transactions on top of the version
>>control mechanism envisaged in WEB-DAV
>>
>>Response:
>>
>>The transaction protocol being worked in W3C and IETF will address this
>>requirement
>>
>>Reposte:
>>
>>Duh! What we are asking for is different. Do we need to explain this or
>>refer you folks to several papers that describe the concept of
>>environments/contexts in cooperative transaction processing.
>
>The working group has decided on many occasions not to pursue transaction
>support.  To consider adding such a requirement, you need to resolve
>several questions: What features do you want to support with this context
>information?  Why do we need to have WebDAV clients and servers supporting
>this information?  Why are cookies insufficient?
>
>Perhaps posting the papers references you mentioned would help me to better
>understand your position.  Right now all I'm hearing is "we gotta have it"
>without (to my mind) really understanding either "it" or why it is so
>necessary.

I have to concur that generalized transaction support should not be
pursued by this working group.  General transaction support is a hard
problem ("Transaction Processing: Concepts and Techniques" (a good guide
to the issues) is over 1000 pages, not just a journal article).  It will
likely take a look at the whole issue before transaction processing can
be added to HTTP.  (It may even take HTTP 2.0 to do so.)
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
fisherm@indy.tce.com          Indianapolis, IN
"Browser Torture Specialist, First Class"

Received on Tuesday, 29 July 1997 10:13:59 UTC