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

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.

Nikunj
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
>
>

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

Received on Wednesday, 29 July 2009 21:16:34 UTC