- From: Aaron Boodman <aa@google.com>
- Date: Fri, 24 Jul 2009 14:06:58 -0700
- To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
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. 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). 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). 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. When we designed the HTML5 version of the database API we specifically tried to avoid it. I do not agree that database-level locking is a big problem for web applications. They are typically serving as most a handful of clients. As long as you can specify read vs read/write transactions, I think the current design is the correct trade-off in terms of complexity and correctness. - a
Received on Friday, 24 July 2009 21:07:38 UTC