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

On Thu, Feb 17, 2011 at 3:58 PM, Pablo Castro <Pablo.Castro@microsoft.com>wrote:

>
> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org]
> On Behalf Of Jeremy Orlow
> Sent: Thursday, February 17, 2011 11:51 AM
>
> >> 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.
>
> This sounds reasonable to me (special case and abort the transaction only
> for blocked setVersion transactions). We should capture it explicitly on the
> spec, it's the kind of little detail that's easy to forget.
>

Captured in http://www.w3.org/Bugs/Public/show_bug.cgi?id=12114