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

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

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 24 Jul 2009 14:54:36 -0700
Cc: Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>, Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
Message-Id: <7B7CA00F-F654-4F57-BD05-091E393596A7@oracle.com>
To: Aaron Boodman <aa@google.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 GMT

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