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

[Chris Jones]

Aaron Boodman wrote:
> 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.
> 
>> 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.
> 
> 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.
>
>> 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.
> 

Ay, there's the rub: I think the disagreement is between "mutex" vs. 
"transaction" semantics.  So far, I think perhaps "mutex" has been used 
as shorthand for "transaction."  But they aren't the same.

I think we all agree that a script may fail to modify localStorage in 
some situations (irrespective of global mutex vs. per-domain mutex). 
One camp, wanting "mutex" semantics, would prefer to pretend that the 
failures never happen and let scripts clean up the mess 
(partially-applied changes) if they do occur.  This is semantically 
broken, IMHO.

The second camp, wanting "transaction" semantics, explicitly acknowledge 
to web authors that localStorage is fallible, guarantee that 
modifications to localStorage are atomic, and notify scripts when 
modifications can't be made atomically.  This is the same approach taken 
by Web Database.  IMHO, this is much better semantically because (i) it 
gives web apps stronger guarantees; and (ii) it makes the discussion 
about global mutex/per-domain mutex/non-blocking an implementation issue 
rather semantic issue, as it should be.

Can those in the first camp explain why "mutex" semantics is better than 
"transaction" semantics?  And why it's desirable to have one DB spec 
specify "transaction" semantics (Web Database) and a second specify 
"mutex" semantics (localStorage)?

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

I think this is an orthogonal issue concerning per-"tab" script 
responsiveness vs. author friendliness.  One could argue for async-only, 
sync-only, or both.

Cheers,
Chris