[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

[Aaron Boodman]

On Tue, Sep 8, 2009 at 1:41 AM, Robert O'Callahan<robert at ocallahan.org> wrote:
> What is the intended semantics here? Chris' explicit commitTransaction would
> throw an exception if the transaction was aborted due to data inconsistency,
> leaving it up to the script to retry --- and making it clear to script
> authors that non-storage side effects during the transaction are not undone.
> How would you handle transaction aborts?

Calls to transaction() are queued and executed serially per-origin
with exclusive access. There is no such thing as a transaction abort
because there cannot be consistency problems because of the serialized
access.

> You'd have to implement it via a mutex.

I think you would have a queue of all pending requests for access to
storage, along with their associated callbacks, message loops, and
execution environments. Each time the local storage frees up, if there
is any queued request, invoke the callback in the correct environment.

> An optimized implementation could
> wait until the first operation that can't be un-done before acquiring it,
> and do everything optimistically until then.  This is the same situation as
> WebDatabase if I understand it correctly.

You can't do this because upgrading the lock could block the UI
thread. Same thing with the database spec.

If you want to get fancy, the transaction() method can take a
read/write param. This is what the database spec does, but I think it
is overkill here, personally.

- a