- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Thu, 17 Feb 2011 23:58:49 +0000
- To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
- CC: ben turner <bent.mozilla@gmail.com>, public-webapps WG <public-webapps@w3.org>
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. -pc
Received on Thursday, 17 February 2011 23:59:23 UTC