[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
cjones at mozilla.com
Tue Sep 8 11:23:47 PDT 2009
In general, I agree with Rob about this proposal. What problem with
storage mutex as spec'd today does your proposal solve?
I'm eagerly willing to concede explicit
beginTransaction()/commitTransaction() for a window.transaction()
wrapper that implicitly does those.
Aaron Boodman wrote:
> 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
No, transactions can still fail. They can fail in ways immediately
hidden from the script that requested them if the UA has to interrupt
the conceptually executing transaction in the ways enumerated in a
separate branch of this thread. Later script executions can observe
inconsistent state unless more is specified by your proposal.
Transactions can also fail visibly if write-to-disk fails (probably also
in other ways I haven't considered). It's not clear what should happen
wrt to your proposal in this case.
(We could pretend that these failures never occur, but IMHO my original
proposal handles both naturally.)
>> 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.
I have to admit that I didn't closely read the Web Database spec before
making the OP. Like Rob, my scan of the text led me to believe that it
provided an API to asynchronously execute SQL free from script side
effects. It does *not*. Arbitrary side-effecty script statements can
execute within Web Database transactions. And these transactions can be
synchronous. And like my OP concerning localStorage, Web Database
transactions are allowed to fail by the spec.
In fact, I believe that the "Synchronous database API" describes the
same transaction semantics as I proposed in the OP. That spec adds
implicit begin/commitTransaction and read-only transactions, but
otherwise the semantics are the same.
So I'd like to amend my original proposal to be
Use Synchronous Web Database API transaction semantics. Except do
not offer readTransaction: a transaction is implicitly a read-only
transaction if only getItem() is called on localStorage from within
SELUAs (single-event-loop UAs) can implement this semantics without
mutexes. MELUAs (multi-event-loop UAs) can implement this semantics
with mutexes, but more interesting and performant non-blocking
implementations also seem possible (which is what I had in mind with the
More information about the whatwg