Closed
Bug 568095
Opened 15 years ago
Closed 13 years ago
DOM Storage should write asynchronously
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 627635
People
(Reporter: mak, Unassigned)
References
(Blocks 1 open bug)
Details
Mostly investigation bug.
DOM storage is not thread-safe, the specs talk about storage mutex, but there is lot of chit-chat (And complains) around that approach.
We could at least try to make the situation better moving IO out of the main thread.
The current database solution involves 3 different databases, memory ones are managed through hashes, disk one through sqlite. this looks far more complicated that what is needed.
We could do something similar to what we did in Places, we will remove that from Places because our schema involves many tables and is complicated, but should work pretty fine for the single table we have here.
Have a memory table and a disk table in a single database, partition data across them. you always write to the temp table, data is synced asynchronously on the disk table, privatebrowsing stuff can just stay in the temp table and be removed from there, session stuff can just be not synced down.
Reads hit the memory table and if the data is not there the disk table.
each row in the mem table can have a column indicating
0 - sync to disk
1 - don't sync
2 - pb
Comment 1•13 years ago
|
||
sounds like mostly a dupe of bug 627635.
Reporter | ||
Updated•13 years ago
|
Blocks: StorageJank
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•