W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 17 Feb 2011 11:50:31 -0800
Message-ID: <AANLkTikhbro35LrqB1eX9RGwsq4yx+xyLsogzx7HcHez@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: ben turner <bent.mozilla@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Feb 17, 2011 at 11:02 AM, ben turner <bent.mozilla@gmail.com>
> wrote:
> >>> Also, what should we do when you enqueue a setVersion transaction and
> then
> >>> close the database handle?  Maybe an ABORT_ERR there too?
> >>
> >> Yeah, that'd make sense to me. Just like if you enque any other
> >> transaction and then close the db handle.
> >
> > We don't abort transactions that are already in progress when you call
> > db.close()... We just set a flag and prevent further transactions from
> > being created.
>
> Doh! Of course.
>
> If the setVersion transaction has started then we should definitely
> allow it finish, just like all other transactions. I don't have a
> strong opinion on if we should let the setVersion transaction start if
> it hasn't yet. Seems most consistent to let it, but if there's a
> strong reason not to I could be convinced.
>

What if you have two database connections open and both do a setVersion
transaction and one calls .close (to yield to the other)?  Neither can start
until one or the other actually is closed.  If a database is closed (not
just close pending) then I think we need to abort any blocked setVersion
calls.  If one is already running, it should certainly be allowed to finish
before we close the database.

J
Received on Thursday, 17 February 2011 19:51:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT