[whatwg] executeSql API is synchronous

[Maciej Stachowiak]

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