RE: Must PROPPATCH operation be atomic...

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.  Some reasons for the second case:

 - Clients don't have to grovel through the 207 multi-status to find the
ones which would have worked, and try them again.  

 - Servers may be able to be more performant without having to implement
some dort of transactioning for PROPPATCH.  Of course this depends on the
server implementation, what's under it, how important performance is and
what operations need to be performant.

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.

Lisa

> -----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 Tuesday, 20 April 1999 23:18:55 UTC