- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Fri, 24 Jul 2009 14:54:36 -0700
- To: Aaron Boodman <aa@google.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
On Jul 24, 2009, at 2:06 PM, Aaron Boodman wrote: > On Fri, Jul 24, 2009 at 1:54 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com > > wrote: >> Experience has shown that there is no easy way out when dealing with >> transactions, and locking at the whole database level is no >> solution to >> failures. > > The thing that makes the web browser environment different an > interesting is that multiple independent applications can end up > having access to the same database if the run in the same origin. Applications have the ability to specify which database they want to use. So I don't see problems in apps sharing an origin. > This could be multiple instances of the same app (eg multiple gmail > windows) or just different apps that happen to be on the same origin > (many Google apps run on www.google.com). When running multiple instances of the same application, or when different applications share the same data, you are beginning to deal with multi-user applications (even though it may be the same security principal). In multi-user applications, database transactions are the same as what they are on the server. Applications have no choice but to be careful in performing transactions. Let me illustrate this with an example. Say that I had a spreadsheet app. The value of a cell was displayed to the user as X. Now, I go in to one tab A and say "add five to X". I also go in to B and say "add five to X". One of those operations will have to fail because it finds that the version of X is not what it was when the transaction started out. Even if you put a lock on the entire database, you can't avoid that problem. It seems that the way the spec is written, novice programmers would be led to either 1. face lost updates because they assume the browser locks the entire database, and so they won't bother to do their own analysis of whether data has changed since the last time they saw it. 2. create single-instance-only apps , i.e., hold a write lock on the database forever since they don't want to deal version checks. > > Because these apps are isolated from each other, they have no way to > cooperate to reduce conflicts. They also have no control over whether > there are multiple copies of themselves (the user control this). Sorry, but there is postMessage, localStorage, and the database itself. What do you mean these apps are isolated and have no way to cooperate? > > Therefore if the platform does not protect against this, basically any > statement can fail due to conflict. This was a big problem with Gears, > and led to applications having to go to crazy contortions to do things > like master election. I will assert that the platform can't solve all transaction failures by changing the granularity of concurrency control. Otherwise, we wouldn't have database designers going to extremes with serializability protocols. > > When we designed the HTML5 version of the database API we specifically > tried to avoid it. > I am perplexed that you expect a poor programmer to understand transactions but not understand recovery. > I do not agree that database-level locking is a big problem for web > applications. Our problem is not with databases doing database-level locking. Our problem is that such behavior is a MUST. > They are typically serving as most a handful of clients. Up to one concurrent user, it doesn't matter. When you have even two users, the game changes completely. Nikunj http://o-micron.blogspot.com
Received on Friday, 24 July 2009 21:57:04 UTC