[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage
jorlow at chromium.org
Tue Sep 8 16:31:58 PDT 2009
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
>>> 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>
>>>>> What is the intended semantics here? Chris' explicit commitTransaction
>>>>> throw an exception if the transaction was aborted due to data
>>>>> 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
>>>>> 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
>>> 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
>>> other ways I haven't considered). It's not clear what should happen wrt
>>> 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
>>> if only getItem() is called on localStorage from within
>> 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
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,
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...
More information about the whatwg