W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

[IndexedDB] Closing connection in a versionchange transaction

From: Joshua Bell <jsbell@chromium.org>
Date: Fri, 30 Nov 2012 15:26:36 -0800
Message-ID: <CAD649j5K-Rct_kjV74N5XKjwXWEx3H-k_iDuKPf=t0rgm1_dEw@mail.gmail.com>
To: public-webapps@w3.org
A spec oddity that we noticed - if you explicitly close a connection during
an upgradeneeded handler (or elsewhere in the transaction), the transaction
should complete (not abort) yet the connection fails (error), upgrading the
database but leaving you without a connection.

Example:

var req = indexedDB.open('db' + Date.now(), 2);
var db;
req.onupgradeneeded = function() {
  db = req.result;
  var trans = req.transaction;
  trans.oncomplete = function() { alert("transaction completed"); }; //
should show
  db.createObjectStore('new-store');
  db.close();
};
req.onsuccess = function() { alert("unexpected success); }; // should NOT
show
req.onerror = function() { alert("connection error, version is: " +
db.version); }; // should show, with 2

... and a subsequent open would reveal that the version is 2 and the the
store exists.

This behavior is specified by 4.1 "Opening a database" step 8: ...If the
"versionchange" transaction in the previous step was aborted, or if
connection is closed, return a DOMError of type AbortError and abort these
steps. In either of these cases, ensure that connection is closed by
running the steps for closing a database connection before these steps are
aborted.

... and the specifics of 4.10 around closePending, which ensure that
calling close() has no effect on running transactions.

Chrome 24 alerts "connection error, version is: 2"
Firefox 17 alerts "unexpected success"

The one spec wrinkle might be that in 4.10 "Database closing steps", the
spec says "Wait for all transactions _created_ using /connection/ to
complete..." where _created_ references "A transaction is created using
IDBDatabase.transaction." which is not true of versionchange transactions.
Received on Friday, 30 November 2012 23:27:06 GMT

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