To add my 2p worth to all this....
I am not fully aware of the Firefox internals, buts as far as my
understanding goes only one process can use any profile at any time. If
two "instances" of firefox are fired up for the same user (+ profile)
then what happens as far as I understand is another thread is started of
the first process for the second instance.
The way I would tackle replacing profile data with SQLite is to enforce
single processes per profile with a lock file (I believe this is already
done), and on start of (the first instance of) Firefox to fire up a
special database thread that opens the database exclusively - thus
ensuring no on-the-fly locking is required probably taking care of
performance issues. Any accessing of the database by Firefox is then
done by passing requests to this special thread (using mutexes, waits
and signals and a global area), the thread then retrieves/updates the
data and passes the result back to the "calling" thread.
Although this is slightly more complex than otherwise, ot is not much
more. It also should increase performance (no on-the-fly locking as
only one connection is made), increases stability as passing multiple
queries through a single connection in an embedded database is really a
no-no and does the functions required.
Yours
Eddy
Brett Wilson wrote:
Hi everybody,
I'm working on replacing a lot of Firefox's storage systems to use
sqlite. It has been going well so far except for one issue.
The database file is stored in the user's Mozilla profile directory.
In companies and Universities using Linux, this directory is often
hosted over the network. In these cases, sqlite performance can be
quite poor.
I am aware that writing performance can be bad in these cases, but we
don't do too many writes. I am mostly concerned about read
performance, since a lot of this stuff (history, bookmarks) drive the
UI. The lag, even over a fast network, can be noticable. I am also
concerned about file locking, since the documentation does not
recommend using files over the network.
Can anybody suggest what to do about this problem? This is not
something that can be avoided, since some people will have this
configuration and will not have any say about it. Firefox must perform
reasonably in these cases.
One thing that could work in our favor is that Mozilla already does
locking on the profile, so access will be restricted to our one
process. Is there anything that we can do to take advantage of this to
avoid having to query the file for reads even when the content is
cached? It looks like we will have multiple database connections from
this process.
I will work on minimizing the number of queries in the common cases,
but any little bit of perfomance will help here.
Thanks,
Brett
