[whatwg] database transactions should be serialized

Aaron Boodman aa at google.com
Mon Aug 4 13:24:08 PDT 2008


I think this has been covered in passing before, but I wanted to bring
it up explicitly.

Currently, the database API has an error code for the situation where
you open a transaction for read, then try to write but the database is
locked.

I think that the spec should at least suggest, but perhaps require,
implementors to serialize access to a single database to prevent this
from happening. Without this, developers must wrap every single write
attempt in error handling and retry if a lock error occurs.

It seems likely that developers will forget to do this and it will be
a significant pain point with the API. Applications will seem to work,
but then mysteriously fail in production when users have multiple
copies of the application open.

Even if the developer adds retry logic, it is easy for a page to get
starved by another page.

Serializing access would prevent all these problems at the cost of
read concurrency, which I think is OK for the first version of this
API. A future version of the API could add the concept of "read
transactions" which would allow concurrency, but would fail
immediately when you try to write with them.

- a



More information about the whatwg mailing list