- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 9 Sep 2009 08:31:58 +0900
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.htm>
Received on Tuesday, 8 September 2009 16:31:58 UTC