Re: [WebStorage] Concerns on spec section 'Processing Model'

On Wed, 29 Jul 2009, Nikunj R. Mehta wrote:
> On Jul 24, 2009, at 3:57 PM, Nikunj R. Mehta wrote:
> > On Jul 24, 2009, at 3:11 PM, Ian Hickson wrote:
> > > On Fri, 24 Jul 2009, Nikunj R. Mehta wrote:
> > > > On Jul 24, 2009, at 2:53 PM, Ian Hickson wrote:
> > > > > 
> > > > > These are very different from concurrency bugs.
> > > > 
> > > > There are only three concurrency "bugs"
> > > > 
> > > > 1. The Lost Update Problem
> > > > 2. The Temporary Update (or Dirty Read) Problem
> > > > 3. The Incorrect Summary Problem.
> > > > 
> > > > Neither of these is related to the granularity of locking. All of these
> > > > are solved through the use of transactions.
> > > > 
> > > > If an application uses transactions correctly, then it is free from
> > > > concurrency bugs.
> > > 
> > > If you have two applications in two tabs, and they both need to read row
> > > A, then write to row B, and they start doing these two tasks
> > > simultaneously, how do you prevent either from failing if you don't have
> > > database-wide locking?
> > 
> > First of all, the value of row A never changes in this example. So it is
> > immaterial whether the transaction locked the whole database or just row B.
> > Your application that wrote this kind of a query/update has a concurrency
> > bug, namely lost update. IOW, it is losing the first update because it did
> > not check the value of B before modifying it and didn't modify row A when it
> > modified row B.

You are correct, I should have said write to row A, not B. My point still 
stands, however.

For further discussion, please see the e-mail I sent earlier today:

   http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0432.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 29 July 2009 22:31:41 UTC