On Thu, Dec 10, 2009 at 10:36 PM, Joran Greef <jo...@sexbyfood.com> wrote:
> "The use of the storage mutex to avoid race conditions is currently > considered by certain implementors to be too high a performance burden, to > the point where allowing data corruption is considered preferable. > Alternatives that do not require a user-agent-wide per-origin script lock > are eagerly sought after." > > It's not a question of mutex versus data corruption, but of implementation: > > Database storage is served by SQLite. LocalStorage would be better served > by Tokyo Cabinet: http://1978th.net/tokyocabinet/. I doubt the current > localStorage implementation is better than the current Tokyo Cabinet > implementation. > The issue has nothing to do with SQLite. If you support run-to-completion (i.e. require serialization) and can't abort and retry a transaction (which the LocalStorage API doesn't support) then there's no way around locking as far as I know. If you're arguing there is, can you please explain how (rather than linking to a rather large document)? Thanks, J