Aaron Boodman wrote:
On Tue, Sep 8, 2009 at 11:23 AM, Chris Jones<cjo...@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<rob...@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
