- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Wed, 29 Jul 2009 14:14:08 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps WG <public-webapps@w3.org>
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