On Thu, Sep 10, 2009 at 1:59 AM, Chris Jones <span dir="ltr"><<a href="mailto:cjones@mozilla.com">cjones@mozilla.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Jeremy Orlow wrote:</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What failures could there be in a pesimistic/queue model?<br>
</blockquote>
<br></div>
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.)<br>


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


<br>
And second, can scripts be notified that the transaction failed (or was only partially applied) because of quota exceeded?<br>
<br>
AFAICT this is irrespective of sync/async/optimistic/pessimistic/queue.  Any implementation has to deal with this error somehow.<br>
<br>
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.<br>


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


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


<br>
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.)</blockquote>

<div><br></div><div>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).</div>

<div><br></div><div>I don't think quota errors should be grouped in with any atomicity guarantees, in other words.</div><div><br></div><div>Are there any other examples of failures you can have within a pessimistic transaction?</div>

</div>