Bug with IndexedDB upon page reload
816 views
Skip to first unread message
Julien Genestoux
Oct 31, 2011, 1:44:16 PM10/31/11
to Hans Wennborg, David Grogan, Chromium HTML5
Hans, David,
I am facing a bug with IndexedDB but I have a hard time writing a script that reproduces it.
Basically, it happens when I refresh the page while there is still a cursor reading values from a store. When doing this, IndexedDB seems to be "lost" in a state that blocks it all.
When trying to reload the page, the cursor shows this in the console :
IDBRequest
errorCode: [Exception: IDBDatabaseException]
onerror: null
onsuccess: function (e) {
readyState: 1
result: [Exception: IDBDatabaseException]
source: IDBIndex
transaction: IDBTransaction
webkitErrorMessage: [Exception: IDBDatabaseException]
__proto__: IDBRequest
Also, note that when the app is blocked, no other IndexedDB database can be accessed from any "window/host", so I think this is pretty serious, as it means a buggy implementation can block other services's implementations :(
Restarting Chrome (or reloading the extension) just fixes the issue.
I have tried to write a script that does just that, but I can't seem to recreate the issue in it.
If you want to see it by yourself, it's possible: just clone the code for this chrome extension: https://github.com/superfeedr/msgboy/tree/indexeddbbug
then, in Google Chrome (any version), go to chrome://extensions/, click on "Developer Mode", then "Load Unpacked Extension" and select the director where you cloned the extension. Now, you will see screen that shows you boxes. The content of these boxes is loaded from IndexedDB. If you reload the window quickly, you will see that that stop loading : this is the issue I am describing. Feel free to checkout the file lib/backbone-indexeddb/backbone-indexeddb.js (line 234 is where the cursor is displayed).
I would really really appreciate some help. I know this is quite limited a s bug report, but I am stuck with it :(
Thanks
--
"Stay hungry, stay foolish"
Joran Greef
Nov 21, 2011, 8:06:16 AM11/21/11
to chromiu...@chromium.org, Hans Wennborg, David Grogan
Yes, I'm developing for IndexedDB and am seeing the same bug with Chrome several times a day.
On a related note, Chrome seems to be serializing all transactions regardless of whether they are read or write. So even if you don't have a single write transaction running, your read transactions will be forced to execute one at a time, and any subsequent write transactions will have to wait until those read transactions finish. There is no MVCC, so a single writer will block not just other writers but also all readers. What one would expect is that writers block writers, but writers never block readers, and readers never block writers, and readers never block other readers. So writers should be serialized, readers should be concurrent irrespective of writers.
Back to the bug, it may be a running read transaction not being terminated when a tab is closed or reloaded, leaving the database locked until Chrome is rebooted.
Hans Wennborg
Nov 21, 2011, 11:36:26 AM11/21/11
to chromiu...@chromium.org, David Grogan, Joshua Bell
On Mon, Nov 21, 2011 at 1:06 PM, Joran Greef <jo...@ronomon.com> wrote:
> On a related note, Chrome seems to be serializing all transactions
> regardless of whether they are read or write. So even if you don't have a
> single write transaction running, your read transactions will be forced to
> execute one at a time, and any subsequent write transactions will have to
> wait until those read transactions finish. There is no MVCC, so a single
> writer will block not just other writers but also all readers. What one
> would expect is that writers block writers, but writers never block readers,
> and readers never block writers, and readers never block other readers. So
> writers should be serialized, readers should be concurrent irrespective of
> writers.
> On a related note, Chrome seems to be serializing all transactions
> regardless of whether they are read or write. So even if you don't have a
> single write transaction running, your read transactions will be forced to
> execute one at a time, and any subsequent write transactions will have to
> wait until those read transactions finish. There is no MVCC, so a single
> writer will block not just other writers but also all readers. What one
> would expect is that writers block writers, but writers never block readers,
> and readers never block writers, and readers never block other readers. So
> writers should be serialized, readers should be concurrent irrespective of
> writers.
Yes, the current implementation runs all transactions serially,
irrespective of whether they're read or write transactions. We plan to
fix this, and track it at crbug.com/64076, but it could take a while.
Thanks,
Hans
Joshua Bell
Nov 23, 2011, 1:01:31 PM11/23/11
to chromiu...@chromium.org, Hans Wennborg, David Grogan
On Mon, Nov 21, 2011 at 5:06 AM, Joran Greef <jo...@ronomon.com> wrote:
Yes, I'm developing for IndexedDB and am seeing the same bug with Chrome several times a day.
[snip]
Back to the bug, it may be a running read transaction not being terminated when a tab is closed or reloaded, leaving the database locked until Chrome is rebooted.
Reply all
Reply to author
Forward
0 new messages