568095 - DOM Storage should write asynchronously

Status: RESOLVED DUPLICATE of bug 627635

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

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

[Dietrich Ayala (:dietrich)]

sounds like mostly a dupe of bug 627635.