[whatwg] executeSql API is synchronous

Maciej Stachowiak mjs at apple.com
Wed Aug 8 16:46:49 PDT 2007

On Aug 8, 2007, at 2:05 PM, Aaron Boodman wrote:

> FWIW, We (the gears team) considered adding an async version of our
> sql execute() method, but decided against it in favor of improving the
> workerpool.
> Async APIs work OK for a few requests, but a single logical update to
> a local database might be made up of many SQL statements. Stringing
> these all together with async APIs is a big pain, especially if
> results must be passed between the statements.
> A background worker allows you to express long strings of database
> logic in simple synchronous code. You can even intermingle
> _synchronous_ httprequests between the database operations. So
> synchronization logic, for example, turns into simple looping code.

Sounds like worker threads might be a better solution, but either way  
I think the spec should address this.


> - a
> On 8/8/07, Maciej Stachowiak <mjs at apple.com> 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.
>> Regards,
>> Maciej

More information about the whatwg mailing list