Closed Bug 568095 Opened 15 years ago Closed 13 years ago

DOM Storage should write asynchronously

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

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
sounds like mostly a dupe of bug 627635.
Blocks: StorageJank
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.