W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Aaron Boodman <aa@google.com>
Date: Fri, 24 Jul 2009 14:06:58 -0700
Message-ID: <278fd46c0907241406n7e7e3377kfa145b133043e5ab@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT