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

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<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.

(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

Received on Tuesday, 8 September 2009 11:23:47 UTC