On Jul 24, 2009, at 2:06 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 1:54 PM, Nikunj R. Mehta<nikunj.me...@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
