Switch IndexedDB transactions to be non-durable by default
Categories (Core :: Storage: IndexedDB, defect) Core ▾Core
Shared components used by Firefox and other Mozilla software, including handling of Web content; Gecko, HTML, CSS, layout, DOM, scripts, images, networking, etc. Issues with web page layout probably go here, while Firefox user interface issues belong in the
Firefoxproduct. (
More info)
Storage: IndexedDB ▾Core :: Storage: IndexedDB
IndexedDBimplementation, exposed through self.indexedDB.
Webcompat Score Accessibility Severity Size Estimate Webcompat Priority a11y-review Performance Impact Tracking Status firefox40 --- fixed relnote-firefox --- 40+ Tracking Status firefox40 relnote-firefox thunderbird_esr115 thunderbird_esr128 thunderbird_esr140 firefox-esr115 firefox-esr128 firefox-esr140 firefox140 firefox141 firefox142 People (Reporter: bent.mozilla, Assigned: bent.mozilla)Reset Assignee to default
Details (Keywords: dev-doc-complete)Bug Flags:
in-testsuite + in-testsuite behind-pref firefox-backlog sec-bounty sec-bounty-hof in-qa-testsuite qe-verifyThis bug is publicly visible.
The proposal is to change our IndexedDB write transactions to more closely align with Chrome/IE which favor performance over durability. We will have an opt-in mechanism to have per-transaction durability for consumers that care.
Can you clarify the risk profile here? Specifically, a crash shortly-after a non-durable transaction commits may result in: A) Database corruption. The whole database may need to be blown away because the pages of the database may not be in a coherent state. (non-WAL PRAGMA SYNCHRONOUS=0/OFF, low probability on non-WAL PRAGMA SYNCHRONOUS=1/NORMAL) B) Loss of the most recent transaction but the database should probably be coherent. (non-WAL PRAGMA SYNCHRONOUS=1/NORMAL) C) Loss of multiple recent transactions but the database will still be coherent at that earlier point. (WAL with SYNCHRONOUS=1/NORMAL and where a checkpoint is not triggered) Since IndexedDB currently uses PRAGMA synchronous=2/FULL, I'm assuming this is a proposal to drop to NORMAL or OFF? Or is the idea to switch to using WAL with PRAGMA synchronous=1/NORMAL and the opt-in mechanism would just make sure to trigger a checkpoint as part of the transaction? The WAL option sorta sounds preferable since the non-WAL options seem more likely to result in database corruption, requiring apps to make every transaction be durable. Or to shard things so that there is one IndexedDB database that is where the really important stuff is (config, drafts for email), and another happy-go-lucky DB for stuff that isn't authoritative (synced email).
IDB currently runs with non-WAL and SYNCHRONOUS=NORMAL (unless you set an obscure pref that might flip it to FULL). The change will be to make normal write transactions run with WAL and SYNCHRONOUS=NORMAL. If WAL mode isn't available for some reason then we'll still use SYNCHRONOUS=NORMAL. The specially-opted-into durable write transactions will essentially run with WAL and SYNCHRONOUS=FULL (it won't actually because we're changing the way we use connections, but that'll be the end result).
Awesome. Thanks for the clarification!
We're absolutely not going to introduce opportunities for database corruption.
(In reply to ben turner [:bent] (use the needinfo? flag!) from
comment #3)
> (it won't actually because we're changing the way we use connections, > but that'll be the end result).Through manual checkpointing.
This gives us an optional mode to say "no, really, I want it on disk".
Flags: needinfo?(bent.mozilla)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Release Note Request (optional, but appreciated) [Why is this notable]: This will have an impact on devs. [Suggested wording]: IndexedDB transactions now non-durable by default [Links (documentation, blog post, etc)]:
Flags: needinfo?(bent.mozilla)
Is there any examples that will be affected by this change? I see the new readwriteflush mode in the patch but readwrite is still the default mode, right?
Flags: needinfo?(bent.mozilla)
(In reply to Kohei Yoshino [:kohei] from
comment #16)
> Is there any examples that will be affected by this change? I see the new > readwriteflush mode in the patch but readwrite is still the default mode, > right?Well, the default mode for transactions is actually 'readonly'. But the new 'readwriteflush' mode is not available unless you have enabled the indexedDB experimental feature preference. Without that preference set you are only able to use 'readonly' and 'readwrite'.
Flags: needinfo?(bent.mozilla)
Oh I meant 'readonly', of course I know that because my app uses IndexedDB. > optional IDBTransactionMode mode = "readonly" So I guess there would be no backward compatibility issues here.
(In reply to Kohei Yoshino [:kohei] from
comment #18)
> So I guess there would be no backward compatibility issues here.Right.
Thanks! Removing the relnote-firefox flag given the dom.indexedDB.experimental pref is defaulted to false at this moment.
(In reply to Kohei Yoshino [:kohei] from
comment #20)
> Thanks! Removing the relnote-firefox flag given the > dom.indexedDB.experimental pref is defaulted to false at this moment.Well, this change is still worthy of a relnote in my opinion (and see
comment 15). The change won't affect the code that people write but it will affect the timing of the 'complete' event and the behavior in the event of a system crash.
Flags: needinfo?(kohei.yoshino)
Ah, then put the relnote flag back... I don't add the site-compat flag though.
Flags: needinfo?(kohei.yoshino)
Thanks Chris! One thing to note though is that the "readwriteflush" mode is only available if the "dom.indexedDB.experimental" pref is set to true.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4