W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 24 Jul 2009 15:57:52 -0700
Cc: Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>, public-webapps WG <public-webapps@w3.org>
Message-Id: <3FB3E9DB-AAC7-4813-B497-AD5E20ECCBF9@oracle.com>
To: Ian Hickson <ian@hixie.ch>
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.

Therefore, your question itself has a concurrency bug. This is why I  
said that locking is not a silver bullet and multi-user concurrency  
should not be taken lightly. For a primer on isolation levels,  
transactions, and locks, please see [1].

This discussion is an indicator of both the complexity involved in  
designing standards such as these and the amount of background  
knowledge required to design a good standard. Proponents of existing  
spec language have chosen to never explicitly back up their statements  
with the body of knowledge that exists in the database sciences. Taken  
together, all this makes it unlikely that a good SQL standard can be  
developed by this WG in a short period of time that some might be  
expecting.

Nikunj
http://o-micron.blogspot.com

[1] http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html
Received on Friday, 24 July 2009 23:00:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT