Re: Must PROPPATCH operation be atomic...

   From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>

   I've been thinking about this some more, and I believe both are valid
   scenarios.  There are scenarios where the client wants to have all succeed
   or none, and there are scenarios where the client wants to have as many
   succeed as possible.

I agree.

   Really, it's too bad clients don't have some simple switch to say whether
   this should be treated as an entire transaction or not.  Then servers that
   don't support the model that the client asks for could fail the operation
   right away.

And if someone feels the alternative behavior (where as many succeed
as possible) is worth the time and effort to define and get accepted,
he/she should join or form a working group to define such an extension
to the base WebDAV spec.

Cheers,
Geoff

   > -----Original Message-----
   > From: Yaron Goland 
   > Sent: Friday, April 16, 1999 2:25 PM
   > To: Lisa Lippert (Dusseault) (Exchange); 'Brian Lloyd';
   > 'w3c-dist-auth@w3.org'
   > Cc: 'gstein@lyra.org'
   > Subject: RE: Must PROPPATCH operation be atomic...
   > 
   > 
   > To quote section 8.2:
   > 
   > Instructions MUST either all be executed or none executed. 
   > Thus if any error occurs during processing all executed 
   > instructions MUST be undone and a proper error result returned. 
   > 
   > I apologize if this language is not sufficiently clear.
   > 
   > As for multi-status, it is a compound response format. While 
   > a single error is sufficient to cause a PROPPATCH to fail the 
   > system may be programmed to send out commands to set all the 
   > properties and then to roll back if one or more fail. The key 
   > is, one or more. 
   > 
   > For example, a client sends in a PROPPATCH with changes to 
   > four properties. The server sends a command to its property 
   > store to change all four properties. The property store sends 
   > the server back a message saying that three of the property 
   > set commands failed and one succeeded. The server then orders 
   > a roll back. However the server wants to be able to tell the 
   > client exactly what went wrong. That is, the server wants to 
   > send a message to the client saying "Your request failed. The 
   > reason it failed is that there were the following errors on 
   > three of your properties." To do this the server needs a 
   > compound error response format and that is what multi-status does.
   > 
   > As for why we have the atomicity requirement please refer to 
   > the section entitled "<"This is another fine protocol you've 
   > gotten me into!">" in 
   > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0
   > 303.html. I believe the second paragraph exactly answers your 
   > question. Although it seems that my comment regarding 
   > compliance with the atomicity requirement is wrong. Most 
   > folks apparently have implemented it. I think that rocks! I 
   > will eventually have to update the WebDAV book of why to reflect this.
   > 
   > 			Yaron
   > 
   > > -----Original Message-----
   > > From: Lisa Lippert (Dusseault) (Exchange)
   > > [mailto:lisal@exchange.microsoft.com]
   > > Sent: Friday, April 16, 1999 1:48 PM
   > > To: 'Brian Lloyd'; 'w3c-dist-auth@w3.org'
   > > Cc: 'gstein@lyra.org'
   > > Subject: RE: Must PROPPATCH operation be atomic...
   > > 
   > > 
   > > So what does multi-status mean??
   > > 
   > > Ideally there would be a way for the client to specify 
   > > atomicity, but we
   > > don't have that yet.
   > > 
   > > Lisa
   > > 
   > > > -----Original Message-----
   > > > From: Brian Lloyd [mailto:Brian@digicool.com]
   > > > Sent: Friday, April 16, 1999 1:57 PM
   > > > To: Lisa Lippert (Dusseault) (Exchange); 'w3c-dist-auth@w3.org'
   > > > Cc: 'gstein@lyra.org'
   > > > Subject: RE: Must PROPPATCH operation be atomic...
   > > > 
   > > > 
   > > > > I know this is an old conversation, but the email got 
   > buried in my
   > > > > mailbox...
   > > > > 
   > > > > Some PROPPATCH results can fail and others can succeed, so 
   > > > > this is why we
   > > > > have multi-valued responses.  Clients can easily see what 
   > > happened.
   > > > > Rollback is difficult for servers to implement.  Are there 
   > > > any server
   > > > > implementations that do already implement this as atomic or 
   > > > > with rollback?
   > > > > I'm not aware of any.  I see rollback as a more advanced 
   > > > > feature, that we
   > > > > can figure out how to do later on.
   > > > > 
   > > > > Lisa
   > > > 
   > > >  Zope (web application server) implements atomic PROPPATCH 
   > > > w/rollback. We lucked out in this respect, as Zope is
   > > > based on a transactional object database which made this
   > > > relatively painless.
   > > > 
   > > > While implementing it on a non-transactional server is harder,
   > > > it still (IMHO) seems to be a requirement. Clients that respect 
   > > > the rfc will have an expectation that a failure means no changes 
   > > > were made. If this is not the case, you might have any number
   > > > of caching and resource integrity problems, based on mismatched
   > > > expectations on the part of the client and server...
   > > > 
   > > > 
   > > > Brian Lloyd        brian@digicool.com
   > > > Software Engineer  540.371.6909              
   > > > Digital Creations  http://www.digicool.com 
   > > > 
   > > 
   >

Received on Wednesday, 21 April 1999 09:59:27 UTC