RE: "Lost Updates" still persist

A doesn't lock file BANK, reads $200 from file BANK and gets back the e-tag
"foobar".

B locks file BANK, reads the value $200 from file BANK

B adds $50, writes $250 to file BANK, UNLOCKS BANK

A still unaware of B's changes, subtracts $50, writes $150 to file BANK but
adds the header "if-match: "foobar"", as the resource has been changed, thus
its e-tag has been changed, the write FAILS and no damage is done.

So e-tags completely address your concern without requiring locks. Not that
this stops someone from using locks if they so choose.

The bottom line is that "A" depends upon the state of a resource not
changing between messages. This is clearly a faulty assumption. As such A,
as a responsible program, must take appropriate action to ensure that any
assumptions it is making regarding the status of the resource are properly
enforced. Therefore it must either use e-tags, a standard HTTP/1.1 feature,
or it must lock the file. If it chooses, as is its right, to do neither,
then yes, it could cause a lost update. However I would point out that in
some cases this may very well be the intent.

Given that server support for write locks is completely optional we
obviously can not require that a write lock be taken out before making a
change. Furthermore as I have demonstrated there are alternative mechanisms
which a client can use to achieve the goal of preventing a simple lost
update without resorting to a lock, thus even if write lock support was
required it would still be inappropriate to mandate its use for updates.
Finally there are cases where a client has a legitimate reason to not care
about lost updates and so must not be forced to take precautions against a
situation that is of no relevance to them.

As a good standard we can do no more than what we have done, which is to
provide the tools needed to address the various concerns. 

			Yaron

> -----Original Message-----
> From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> Sent:	Friday, February 13, 1998 4:11 PM
> To:	Yaron Goland
> Cc:	'w3c-dist-auth@w3.org'
> Subject:	RE: "Lost Updates" still persist
> 
> Yaron,
> 
> The current spec doesn't enforce client locking.  Here's the problem:
> 
> Let's use a familliar example from the database world:  Since we're
> talking
> basic locking, the equivalent scenario is using the current WEBDAV
> optional locking scheme to handle money transfers from some
> account X - or in this case a single file named 'BANK'. BANK
> starts at $200.  
> 
> A doesn't lock file BANK, reads $200 from file BANK
> B locks file BANK, reads the value $200 from file BANK
> B adds $50, writes $250 to file BANK, UNLOCKS BANK
> A still unaware of B's changes, subtracts $50, writes $150 to file BANK
> 
> Final value: $150.  Should have been $200.
> 
> A has effectively 'lost' fifty dollars worth of B's changes by not
> participating in the locking scheme.  You can imagine how this 
> releates to you updating a file and suddenly noticing that your
> changes have been overwritten inadvertantly.
> 
> From a purely theoreical point of view, I'm sure you'll agree that
> any locking model that doesn't force all participants to participate, is
> equivalent to no locking at all.
> 
> Please let me know if I've overlooked something in the spec.  Otherwise my
> suggestion would be to explicitly specify that all clients have to
> participate
> in locking if the WEBDAV server supports it.
> 
> -San
> 
> P.S. As far as HTTP e-tag's go - since there is no lock involved, checking
> etag's creates a possible starvation condition and still doesn't prevent
> lost updates since the test and file write aren't atomic.
> 
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Thursday, February 12, 1998 3:16 PM
> To:	'Sanford L. Barr'
> Cc:	'w3c-dist-auth@w3.org'
> Subject:	RE: "Lost Updates" still persist
> 
> If a client chooses to not use locking mechanisms available on the server
> then they might suffer from the lost update problem. That is their choice.
> Clients can always do the wrong thing, the onus is on the protocol is to
> make sure it is easy for them to do the right thing.
> 
> Furthermore A could avoid the lost update problem all together without
> ever
> having to take out a lock by using the HTTP e-tag mechanism which all
> HTTP/1.1 compliant servers MUST support. When client A performed the get
> it
> should have received an e-tag. When Client A then performs its put it can
> always submit the e-tag in an if-match header. This says to the server "If
> the get response is not in the same state as identified by this e-tag then
> you must fail this request."
> 
> 			Yaron
> 
> 
> > -----Original Message-----
> > From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> > Sent:	Thursday, February 12, 1998 3:04 PM
> > To:	Yaron Goland
> > Cc:	'w3c-dist-auth@w3.org'
> > Subject:	RE: "Lost Updates" still persist
> > 
> > 
> > Yaron, thanks for taking the time to go over some of the issues with me.
> 
> >  I'd like to go over a few of the other issues with you again, but for
> now
> > 
> > I'd like to focus on the point about optional client locking which sits 
> > unresolved, here's the specifics:
> > 
> > > Lock Ordering - There is no lock ordering requirement, that is
> > completely
> > > under the control of the client. If you want to make sure you don't
> have
> > > lost update issues make sure you lock before you do the GET.
> > 
> > Between this comment and the spec I'm reading "Clients may or may not 
> > choose to participate in locking".
> > 
> > I claim if you don't enforce locking to be adhered to by all clients,
> then
> > 
> > "Lost Updates" for those clients who _do_ lock are still possible.
> > 
> > Here's the scenario from the previous letter in more detail - Here's a 
> > specific example where this fails:
> > 
> > Two clients A and B are interested in editing the file 'index.html'.
> > 
> > Client A doesn't choose to lock the document, does a GET and begins 
> > editing.
> > Client B does LOCK, does a GET and begins editing
> > Client B finishes editing, does  PUT then an UNLOCK
> > Client A does a PUT overwriting and _loosing_ all of B's changes.
> > 
> > As you can see, if a WEBDAV server supports locking, unless all clients 
> > adhere to the locking model.  There is no freedom to allow some clients
> to
> > 
> > simply GET/PUT without locking and still have a valid locking scheme.
> > 
> > Again, my apologies if I've missed something obvious in the spec, but if
> > it 
> > hasn't been addressed, there does seem to be a hole in the current
> locking
> > 
> > design.
> > 
> > My suggestion is that the spec explicity require clients to determine if
> 
> > locking is in use, and if so, the clients must participate by taking
> locks
> > 
> > on the requested documents.
> > 
> > -San
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From:	Yaron Goland [SMTP:yarong@microsoft.com]
> > Sent:	Wednesday, February 11, 1998 10:40 PM
> > To:	'Sanford L. Barr'; 'w3c-dist-auth@w3.org'
> > Subject:	RE: Spec clarifications
> > 
> > Sanford, your points are dead on and identify the areas where WebDAV is
> > working. However I think the core of your concern is the perception that
> > somehow the current Distributed Authoring spec is the end of the
> process.
> > The DA spec is only the first step in a series of specification. It 
> > provides
> > the most absolute basic functions which will then be leveraged by the
> > other
> > specs. So, for example, the next two specs that this working group has
> > committed to delivering are Access Control Lists and Versioning. In 
> > addition
> > a new working group on Search is being formed which is also leveraging
> the
> > DAV specs as its foundation.
> > 
> > Staged Systems - Staged systems are very common, even before the web.
> > However you will notice that the DA spec works perfectly well as a
> > communication mechanism between the editing software and the first
> stage.
> > What is missing is the ability to say "roll this out." The reason that
> > functionality is not in the spec is that so many systems implement this
> > function in so many incompatible ways that the working group came to the
> > decision that it wasn't practical to standardize this functionality. You
> 
> > can
> > only standardize something that is very well understood and is done in
> > essentially the same way by everyone. Standards are not the way to get
> > everyone to agree to do the same thing. Standards are what you use to
> > formalize matters once everyone is doing the same thing, the same way.
> > However the beauty of the DAV specs is that they are like Lego blocks.
> So
> > you can easily take the DA spec and the V spec and the ACL spec and put 
> > them
> > together with a submit command spec. Old DA only compliant systems will
> > still work and will only need a little extra software to be able to give
> 
> > the
> > submit command.
> > 
> > Locking - See section 4.2. But in what I suspect may be a more useful 
> > answer
> > to your question, systems which choose not to supporting write locks
> will
> > suffer from the lost update problem. That is their choice. Although many
> > systems which do not use locks or use shared write locks instead depend 
> > upon
> > advanced merging facilities. The Versioning spec will be addressing the
> > issue of how to handle merging.
> > 
> > Lock Ordering - There is no lock ordering requirement, that is
> completely
> > under the control of the client. If you want to make sure you don't have
> > lost update issues make sure you lock before you do the GET.
> > 
> > Discovering the Source - I'm not sure what more I can say that isn't 
> > already
> > said in section 12.11.
> > 
> > What can be stored in properties - Section 2.4: "The value of a property
> > is
> > expressed as a well-formed XML document." I'm not sure what more can be
> > said.  As for size limits, that is implementation specific.
> > 
> > Reservations - Versioning, including reservations and such, will be
> dealt
> > with in its own specification.
> > 
> > 		Yaron
> > 
> > 
> > > -----Original Message-----
> > > From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> > > Sent:	Wednesday, February 11, 1998 7:22 PM
> > > To:	'w3c-dist-auth@w3.org'
> > > Cc:	'sbarr@interwoven.com'
> > > Subject:	Spec clarifications
> > >
> > >
> > > After reviewing the current -06 draft and mentally mapping the
> protocol
> > > onto existing web collaboration systems, I have the following
> questions.
> > >  Since I'm new to the spec, I apologize if I'm rehashing items that
> have
> > > already been discussed and clarified:
> > >
> > > As I read the spec it seems that the current WEBDAV protocol is very
> > > single
> > > site, live content centric (content is taken directly from a live
> site,
> > > edited and returned directly to the live site).  In all but the
> simplest
> > > organizations this usually isn't the case.  Most corporations that I'm
> > > familliar with have development servers (staging servers, with 
> > individuals
> > >
> > > having separate workareas) from which content is then moved to QA
> > [legal, 
> > > etc.] and then eventually through to a production server.  It doesnt
> > seem 
> > > clear from the current spec how these common authoring environments
> are
> > > addressed by the current WEBDAV draft.  The best I can guess is that a
> > > 'PUT' and the associated 'UNLOCK' could be overloaded to imply an 'OK 
> > move
> > >
> > > the content to the next stage' but a more explicit 'SUBMIT' (an
> explicit
> > > command signifying the completion of a specified unit of work which
> > would 
> > > trigger additional workflow) on a collection of associated items seems
> > > more
> > > in order.
> > >
> > > Has the working group already discussed an approach to this scenario 
> > using
> > >
> > > the current set of defined methods?
> > >
> > > There are also some specifics that seem unclear at first reading:
> > >
> > > *) Client requirements for locking support
> > >
> > > There doesn't seem to be any client requirements for forcing locks to
> be
> > > used if they're supported by the WEBDAV server.  If locking support
> (if 
> > it
> > >
> > > exists on the WEBDAV server) is not strictly required of the clients,
> > the 
> > > "Lost Update" problem will still persist (A does a GET, B does a LOCK,
> > > GET,
> > > edit then PUT, UNLOCK, A then does a PUT overwriting B's changes).
> > >
> > > *) Client lock ordering.  The spec doesn't seem to make mention of the
> > > order of operations when locks are involved.  Specifically, If a
> client
> > > chooses to edit, and locking is supported, the file must be locked
> > before 
> > > the edit can begin, otherwise conflicts can occur.  Currently it seems
> > ok 
> > > for a client to do a 'GET' and then later try to acquire the lock on
> the
> > > item in question (opening up the possibility for the "Lost Update"
> > > scenario
> > > above).  Actually as I reread page 14 it does loosely imply the
> > > lock/get/put/unlock ordering, but this could be more explicit.
> > >
> > > *) How to discover "real" source of a file (seems vague from spec)
> > >
> > > As noted in the spec, one of the more common operations is how to 
> > discover
> > >
> > > the real source(s) of a rendered file (i.e. a file with server side
> > > includes).  The current draft refers to inline 'links', but seems
> vague.
> > >  Was there any consideration of using live properties or another more
> > > defined method to address this?
> > >
> > > *) What can be stored in properties (arbitrary unicode for dead and
> live
> > > values?), any size limits, etc?
> > >
> > > *) No provision for submission 'Reservations'
> > >
> > > The spec only addresses explicit write lock, discusses shared lock but
> > > punts on recommondations.  Many site management systems have a concept
> > of
> > > a
> > > 'Reservation' (guarantee to submit without conflict, while others may
> > > still
> > > be allowed to merge).  While it seems that the current spec has
> > > sidestepped
> > > version control - not being able to coexist with existing systems and
> > > detect conflicts seems to be a significant drawback.  Overall the
> > > exclusion
> > > of versioning in this draft renders the spec almost unusable except
> for
> > > extremely small scale sites (a handful of non conflicting
> contributors).
> > >
> > >
> > > In closing, I'm hoping that the working group will take a careful
> > > consideration of the issues involved with WEBDAV integrating with 
> > existing
> > >
> > > versioning and workflow systems before ratifying the current draft
> > > specification.  I'd personally like to see the industry adopt WEBDAV,
> > but 
> > > in it's current form, the omission of versioning and the lack of
> > enabling 
> > > even the most simple workflow trigger (collection submit) seems to
> limit
> > > its overall usefulness, and makes it difficult to integrate
> effectively
> > > into existing site management, versioning and workflow systems.  I 
> > believe
> > >
> > > with a little extra refinement and discussion the current spec could
> be
> > > extended to address these needs.
> > >
> > > --
> > > Sanford L. Barr
> > > Manager, Internet Technology Group
> > > Interwoven, Inc. 885 N. San Antonio Rd., Los Altos, CA 94022
> > 650/917-3600 
> > > ext 219
>

Received on Friday, 13 February 1998 20:42:21 UTC