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/0303.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 Friday, 16 April 1999 17:27:49 UTC