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