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: Wed, 29 Jul 2009 14:14:08 -0700
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <FA37AE3E-9F54-46AB-A7DB-8119A531F628@oracle.com>
To: Ian Hickson <ian@hixie.ch>
Hi Ian,

I hope you are planning to respond to this email. I think a lot of the  
discussion around "preventing errors" is related to the fallacy in  
your example below.

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.
> 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 Wednesday, 29 July 2009 21:16:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC