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.

Received on Thursday, 17 February 2011 19:51:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:39 UTC