Issue 242115 in chromium: Hanging indexedDB versionchange transaction seems to persist across page loads

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Type-Bug Pri-2

New issue 242115 by aarons...@gmail.com: Hanging indexedDB versionchange
transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Chrome Version : 29.0.1512.0

In both Chrome 26 and 29 (Canary). To reproduce in the console:

var request = window.indexedDB.open('acme');

request = window.indexedDB.open('acme',2);

Even across page reloads, etc., the hanging versionchange transaction seems
to persist. One can no longer successfully open the database, i.e.
window.indexedDB.open('acme');

Only restarting the browser seems to fix this. It seems I can only do a
successful versionchange if I *initially* open the database with the new
version number and onupgradeneeded event. If I try to open it with an
unspecified version, "inspect" the existing database structure, close it,
and then open it again with an increased version number, then I'm stuck
with a pending versionchange transaction and I have to restart the browser.

Please give IndexedDB some love.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 242115 by aarons...@gmail.com: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

If I specify the version number both times, with event listeners for
onupgradeneeded, it seems to work fine. But an initial open with an
unspecified version seems to prevent any subsequent upgrades until a
browser restart.

[chro...@googlecode.com]

Comment #7 on issue 242115 by jsb...@chromium.org: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Also, this should *not* hang across page reloads - those should definitely
clear out the outstanding connections. I haven't been able to reproduce
that behavior, though.

[chro...@googlecode.com]

Comment #11 on issue 242115 by jsb...@chromium.org: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

maxosmail@ - are you explicitly closing the initial connection, or relying
on GC to reclaim it?

[chro...@googlecode.com]

Comment #14 on issue 242115 by mary.r.w...@gmail.com: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Hello - I'm seeing a similar issue intermittently. I'm running Chrome
31.0.1650.63 Mac OS X 10.7.5. Can't seem to create a repro case.

Steps:
1) I have the page open using indexedDb.
2) I increment the DB version in my js file.
3) I refresh the page and call open on indexedDB with the new version.
4) The onblocked event of the open request is fired. (The onupgradeneeded
never fires). On subsequent refreshes, the onblocked event does NOT fire,
but the database never opens (no callback is called at all: not onerror,
not onsuccess, not onupgradedneeded, not onblocked)

If you then kill the tab, and re-open the page. The onupgradeneeded *does*
fire and then everybody proceeds fine.

When you get into state #4, chrome://indexeddb-internals shows one pending
upgrade and each time the page is refresh it adds 2 to the pending open
count. [All that goes away if you kill the tab]

In onsuccess, I listen for the db.onversionchange and close the connection
there. [Any open connection should be getting closed, so I don't understand
why it's getting blocked on the first open.]

Any ideas?

[chro...@googlecode.com]

Comment #19 on issue 242115 by williams...@gmail.com: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Ok I might have something for you here. Basically, I have a main page and
a worker. In the worker, I start a long running transaction which inserts
a few thousand items into the database. In the middle of that tx, I reload
the page, and then I start getting all these pending-upgrades and opens and
delete requests according to chrome://indexeddb-internals which never clear
until you kill the tab.

This honestly might have nothing to do with the worker....I don't have time
to further isolate it. It does seem to have something to do with the
upgrade though, since there is a pending upgrade event in
indexeddb-internals.

Repro Steps:

1) Make sure you start Chrome using the --allow-file-access-from-files
flag so you can launch a local worker.
2) Download both attached files.
3) Open main-test.html in your browser.
4) Look at your console. You'll see a bunch of worker1- inserting item
messages.
5) Refresh the page in the middle of this; there's no rush, I insert a ton
of them.
6) After the refresh, my console never gets past Starting and Starting
reset delete.
7) Open chrome://indexeddb-internals/ and you'll see the pending items
increasing on each refresh.
8) Nothing clears out until I kill the tab, not just refreshing.

Attachments:
main-test.html 2.6 KB
worker.js 1.2 KB

[chro...@googlecode.com]

Updates:
Status: Untriaged

Comment #20 on issue 242115 by jsb...@chromium.org: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #21 on issue 242115 by jsb...@chromium.org: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Thanks - I'll give it a whirl.

[chro...@googlecode.com]

Comment #22 on issue 242115 by mary.r.w...@gmail.com: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Any luck? (Or any way we can just avoid this?)

[chro...@googlecode.com]

Comment #24 on issue 242115 by mary.r.w...@gmail.com: Hanging indexedDB

versionchange transaction seems to persist across page loads
http://code.google.com/p/chromium/issues/detail?id=242115

Ok thanks

[chro...@googlecode.com]

Comment #26 on issue 242115 by bugdro...@chromium.org: Hanging indexedDB

versionchange transaction seems to persist across page loads

http://code.google.com/p/chromium/issues/detail?id=242115#c26

The following revision refers to this bug:
http://src.chromium.org/viewvc/blink?view=rev&rev=165179

------------------------------------------------------------------------
r165179 | jsb...@chromium.org | 2014-01-16T02:17:04.355448Z

Changed paths:
M
http://src.chromium.org/viewvc/blink/trunk/Source/modules/indexeddb/IDBDatabase.cpp?r1=165179&r2=165178&pathrev=165179
M
http://src.chromium.org/viewvc/blink/trunk/Source/modules/indexeddb/IDBTransaction.cpp?r1=165179&r2=165178&pathrev=165179
M
http://src.chromium.org/viewvc/blink/trunk/Source/modules/indexeddb/IDBTransactionTest.cpp?r1=165179&r2=165178&pathrev=165179

IndexedDB: Prevent terminated worker from hanging connections

IndexedDB database connection shutdown is normally blocked on waiting
for transactions to finish. And transaction finishing requires an
abort/onAbort message round-trip to the back-end. When a Worker
context is stopped, the communication channel goes away before the
response comes back, so the transaction never finishes and the
database connection never closes.

Fix by explicitly closing the connection when the execution context is
stopped.

R=alec...@chromium.org,dgr...@chromium.org,cmum...@chromium.org
BUG=242115

Review URL: https://codereview.chromium.org/138473004
------------------------------------------------------------------------