On Aug 8, 2007, at 1:36 PM, Maciej Stachowiak wrote:
http://www.whatwg.org/specs/web-apps/current-work/#executing
The executeSql() API returns a result synchronously. In general, SQL
databases may be slow to access since they need to be read from
disk, and if the database is not open already there's unlikely to be
a ready cache. This may make it hard to use the executeSql() API
without blocking the UI. All other HTML DOM operations that may
require I/O to complete are asynchronous, with the exception of
synchronous XMLHttpRequest which (a) causes UI lockup problems in
practice and (b) at least has an async variant.
The original Google Gears API that inspired executeSql gets around
this by providing a threading facility, so that worker threads can
do all the database access.
I think to make it possible to use executeSql without risk of
harming interactivity, we need either an async version, or a worker
thread API.
With more thought and experience, I am even more convinced this is a
serious problem. I
n WebKit we initially made the mistake of storing favicons in a sqlite
database that was access from the main thread. In some situations this
caused extremely long lockups of the main thread and we had to move
everything to be asynchronous with all database access done on a
background thread. And while it;s bad enough for an in-process
database backed by a normal hard drive disk, things are even worse
when working with a network filesystem (where network problems or
locking protocols can cause awful performance) or a Flash drive (where
some but not all writes can block for a very long time, due to the way
Flash memory works).
We'd like to implement the database API soon in WebKit but this issue
is a showstopper for us.
I would recommend:
- The database access API available on the main thread should be
available *only* in an asynchronous variant. Let's not repeat the
mistake of synchronous XMLHttpRequest.
- If we add some API for background/worker threads, then they can have
access to a synchronous variant.
This way, authors can ultimately choose whether to use the async model
that is familiar to client-side web development (the A in AJAX), or
the Java-like blocking I/O + threads model.
FWIW the async model would probably be easier to implement in the
short run than worker threads, and we'd be hesitant to implement
worker threads at all without a clear spec for which APIs should be
available on worker threads. But in the long run I think having both
is reasonable.
Regards,
Maciej
