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

On Thu, Sep 10, 2009 at 1:59 AM, Chris Jones <cjones at mozilla.com> wrote:

> Jeremy Orlow wrote:
>
>> What failures could there be in a pesimistic/queue model?
>>
>
> I'm trying to think of a "universal failure," something that could arise in
> any implementation of any proposal.  I think that universal failure is
> "exceeded localStorage space quota".  (I believe there are others, but one
> is enough for this discussion.)
>
> So there are really two questions: first, what happens if you detect "quota
> exceeded" in the middle of a localStorage.transaction() callback?  Are the
> modifications made *up to* the quota exceeded error applied to backing
> store?  Or are they rolled back?  This is the atomicity/consistency design
> decision I described: what is the unit of atomic modification (all applied
> or none applied).
>
> And second, can scripts be notified that the transaction failed (or was
> only partially applied) because of quota exceeded?
>
> AFAICT this is irrespective of sync/async/optimistic/pessimistic/queue.
>  Any implementation has to deal with this error somehow.
>
> In the current localStorage spec, if a setItem() fails because space is
> exhausted, it raises QUOTA_EXCEEDED_ERR and does *not* apply any part of the
> change in setItem().  That is, setItem() is atomic --- it either applies or
> not (not partially applied).  But modifications to localStorage *before*
> that failing setItem(), within the same storage mutex acquire/release set,
> *are* applied to backing store.
>
> In the Web Database spec, if executing a SQL statement in a Transaction
> would cause space quota to be exceeded, then *none* of the statements in the
> transaction are executed (i.e. none committed to backing store), and the
> Transaction fails with QUOTA_ERR.  The unit of atomicity for Web Database is
> that Transaction object --- either all statements in Transaction
> successfully execute or none do.
>
> I'm not sure whether you're proposing that modifications within a
> localStorage.transaction() callback are atomic (all applied or none applied)
> in the face of quota exceeded.  (I'm proposing that they *should* be
> atomic.)
>
> It sounds like you're proposing that scripts *cannot* be notified of quota
> exceeded.  If this is true, then there are some semantic issues I'd like to
> discuss.  But I want to make sure we're on the same page first :).  (I'm
> proposing that scripts *should* be able to be notified of this.)


The way it works right now is that an exception is thrown and that's it.  I
think it'd be perfectly acceptable for the behavior to remain, even if it's
inside a "transaction".  In other words, I don't think the transaction
necessarily needs to stop or anything.  I think most app developers will
want to explicitly handle out of space errors (they're not just going to go
away on their own), but probably won't want to explicitly deal with
transient errors (like what you can see with optimistic transactions).

I don't think quota errors should be grouped in with any atomicity
guarantees, in other words.

Are there any other examples of failures you can have within a pessimistic
transaction?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/8a6bd128/attachment.htm>

Received on Wednesday, 9 September 2009 18:57:32 UTC