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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/8/09 3:00 AM, Aaron Boodman wrote:
> On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones<cjones at mozilla.com> wrote:
>> I propose adding the functions
>>
>>  window.localStorage.beginTransaction()
>>  window.localStorage.commitTransaction()
>> or
>>  window.beginTransaction()
>>  window.commitTransaction()
> 
> I think this is a good idea! I would modify it to follow the pattern
> set by the current SQLDatabase proposal, to have a callback, like
> this:
> 
> window.localStorage.transaction(function() {
>   // use local storage here
> });

To be specific, the .transaction function would enqueue an operation to
perform at a later time when a mutex was held. The current caller would
continue to run to completion. There would never be simultaneous
transactions which could potentially conflict with eachother and require
merging or rollback.

It wasn't clear to me when this was proposed that it was asynchronous,
instead of a blocking call that *immediately* waited for the mutex and
blocked script execution.

Would the transaction function be defined so that it never runs immediately
but is always enqueued? Also, I think the function name should make it
clearer that it's an asynchronous callback:
window.localStorage.queueTransaction or somesuch?

> I'm against having explicit begin/commit methods for the same reason
> as I am for the SQLDatabase feature:
> 
> - It is easy to forget to commit
> - The most likely paths in an application to be wrong are ones that
> are rarely run
> - Therefore many applications will contain uncommon paths that end up
> hung (responsive, but still unable to make forward progress) and with
> uncommitted data

I agree that this is true if you never implicitly commit the transaction.
But if you were to implicitly commit the transaction when a script runs to
completion, would that negate the most serious of these issues? I'm defining
"completion" as "all those places where the current spec says the storage
mutex is unlocked", which seems equivalent to "the places script can block
on network or UI activity".

I suspect that making incompatible changes to the existing storage API is
going to be a hard sell for some authors: could we continue to support
completely transaction-free access to storage, in addition to the race-free
queued version. This would allow authors (JS libraries) to do
runtime-detection of the form:

if (window.localStorage.transaction === undefined)
  window.localStorage.transaction = function(fn) {
    window.setTimeout(fn, 0);
  };

- --BDS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKprvbSSwGp5sTYNkRAg33AJwO+WnnwnUu2VB3/UyWQC/w/siYTQCfY4A7
29mcqQmITk2K6PYdodMAMzM=
=ftOi
-----END PGP SIGNATURE-----

Received on Tuesday, 8 September 2009 13:17:32 UTC