Re: Indexed DB: Opening connections, versions, and priority

On Thu, Feb 27, 2014 at 10:51 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 26, 2014, at 10:35 AM, Joshua Bell <jsbell@google.com> wrote:
>
> > While looking at a Chrome bug [1], I reviewed the Indexed DB draft,
> section 3.3.1 [2] Opening a database:
> >
> > "These steps are not run for any other connections with the same origin
> and name but with a higher version"
> >
> > And the note: "This means that if two databases with the same name and
> origin, but with different versions, are being opened at the same time, the
> one with the highest version will attempt to be opened first. If it is able
> to successfully open, then the one with the lower version will receive an
> error."
> >
> > I interpret that as (and perhaps the spec should be updated to read):
> "This means that if two open requests are made to the database with the
> same name and origin at the same time, the open request with the highest
> version will be processed first. If it is able to successfully open, then
> the request with the lower version will receive an error."
> >
> > So far as I can tell with a test [3], none of Chrome (33), Firefox (27),
> or IE (10) implement this per spec. Instead of processing the request with
> the highest version first, they process the first request that was received.
> >
> > Is my interpretation of the spec correct? Is my test [3] correct? If yes
> and yes, should we update the spec to match reality?
>
> I think the ambiguous language in the spec, and also in your substitute
> proposal, is "at the same time". I would think if one request is received
> first, then they are not, in fact, at the same time. Indeed, it would be
> pretty hard for two requests to be exactly simultaneous.
>

Agreed.


> If "at the same time" is actually supposed to mean something about
> receiving a new open request while an older one is still in flight in some
> sense, then the spec should say that, and specify exactly what it means. I
> would think the only observable time is actually delivering the callback.


The spec appears to implicitly describe a queue (or set?) of pending
connection requests, and then how to process them. There's a thread which
touches on this at
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0725.html -
which also points out that "at the same time" is unclear.

The jsfiddle shows how this can happen, when a connection is currently open
and several subsequent requests are blocked by either being a different
version and/or there being a pending delete.

Once several requests are blocked, and become unblocked, one could argue
that these are now available to be processed "at the same time". But as I
said, I agree that the spec's informative NOTE is ambiguous and unhelpful,
despite trying to clarify a normative algorithm.

But ignoring the note and looking at the normative algorithm: am I correct
that this does not appear to match the behavior any of the current
implementations?



> That would imply a rule that if you receive a request with a higher
> version number before the completion callback for a currently pending open
> request has been delivered, you need to cancel the attempt and try with the
> higher version (possibly retrying with the lower version again later).
>

Once a connection request has made it past step 3, neither the spec nor any
implementations appear to abort the steps if another request comes in, but
I'm not sure that's observably different than processing pending requests
in arrival order vs. version order.