In general, I agree with Rob about this proposal. What problem with
storage mutex as spec'd today does your proposal solve?
I'm eagerly willing to concede explicit
beginTransaction()/commitTransaction() for a window.transaction()
wrapper that implicitly does those.
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.
(We could pretend that these failures never occur, but IMHO my original
proposal handles both naturally.)
You'd have to implement it via a mutex.
I think you would have a queue of all pending requests for access to
storage, along with their associated callbacks, message loops, and
execution environments. Each time the local storage frees up, if there
is any queued request, invoke the callback in the correct environment.
An optimized implementation could
wait until the first operation that can't be un-done before acquiring it,
and do everything optimistically until then. This is the same situation as
WebDatabase if I understand it correctly.
You can't do this because upgrading the lock could block the UI
thread. Same thing with the database spec.
If you want to get fancy, the transaction() method can take a
read/write param. This is what the database spec does, but I think it
is overkill here, personally.
I have to admit that I didn't closely read the Web Database spec before
making the OP. Like Rob, my scan of the text led me to believe that it
provided an API to asynchronously execute SQL free from script side
effects. It does *not*. Arbitrary side-effecty script statements can
execute within Web Database transactions. And these transactions can be
synchronous. And like my OP concerning localStorage, Web Database
transactions are allowed to fail by the spec.
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().
SELUAs (single-event-loop UAs) can implement this semantics without
mutexes. MELUAs (multi-event-loop UAs) can implement this semantics
with mutexes, but more interesting and performant non-blocking
implementations also seem possible (which is what I had in mind with the
OP.)
Cheers,
Chris
