- From: Aaron Boodman <aa@google.com>
- Date: Mon, 4 Aug 2008 13:24:08 -0700
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
Received on Monday, 4 August 2008 13:24:08 UTC