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

[Jeremy Orlow]

On Wed, Sep 9, 2009 at 4:39 AM, Chris Jones <cjones at mozilla.com> wrote:

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


The way I understand it, there's 3 camps...and I think they've been abusing
both the word transaction and mutex.  We should probably all start being
more precise with our wording in this respect.  :-)


Those who want pessimistic transactions.  I.e. using locking so that you
never need to do a rollback (because it can never "fail").  This would be
compatible with either a sync or an async interface.

Those who optimistic transactions.  I.e. rollback may happen.  Either we
need to restrict what can be done during a localStorage transaction or we
need to have an exception that tells the script to undo itself.  This was
the original proposal, AFAICT.  It would work with both a sync or an async
interface.

Those who want a queue.  I.e. those who want an asynchronous callback based
interface and the UA will only call one callback at a time.  Perhaps on a
per-origin basis.  Note that this can never "fail", need to be rolled back,
etc.


I believe Aaron is in the queue camp with me.  I'm becoming more and more
convinced that Chromium should/will not implement the storage mutex at all
(even for LocalStorage) unless we can come up with a way for event loops to
not be blocked.  And, as far as I can tell, Async interfaces are the only
way to accomplish this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/13022eed/attachment-0002.htm>