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

[Aaron Boodman]

On Tue, Sep 8, 2009 at 11:23 AM, Chris Jones<cjones at mozilla.com> wrote:
> In general, I agree with Rob about this proposal.  What problem with storage
> mutex as spec'd today does your proposal solve?

The spec requires a single storage mutex for the entire UA. Therefore
in a MELUA a web page can become unresponsive while waiting for some
other page to give up the lock. This is not good and something we have
tried to avoid everywhere else in the spec.

Attempts to address this by doing per-origin locks wind up with
deadlocks being possible.

> I'm eagerly willing to concede explicit
> beginTransaction()/commitTransaction() for a window.transaction() wrapper
> that implicitly does those.

Cool, that is the only point I was trying to make.

> 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
>> access.
>>
>
> 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.

It sounds like you're talking about these issues that you listed a bit earlier:

 * clear private data
 * close tab
 * quit UA
 * "slow script" timeout
 * store-to-disk failure
 * crash

Right?

If so, I agree with roc's responses to them that they could probably
be handled without surfacing errors to the developer.

OTOH, I'm not really against adding the concept of fallibility here.
That wasn't really my point. Mainly, I just think that:

a) We can't have synchronous access to the storage API
b) We should not have an API that requires an author to explicitly
begin and commit transactions

> 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.

Yeah, I meant to correct Rob on that.

> And these transactions can be synchronous.  And
> like my OP concerning localStorage, Web Database transactions are allowed to
> fail by the spec.

Right.

> 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
> localStorage.transaction().

Agree. That is what I was trying to propose, too. I'm not sure where
we disagree :). Is it just that my proposal has no concept of errors?
I'm not against adding them, mainly I was trying to keep my proposal
simple for purposes of discussion.

Note: you're mentioning synchronous transactions here. I think that
the callback for localStorage.transaction() *must* be run
asynchronously to avoid blocking on access to the storage. I presume
this is what you meant. Right?

- a