This was brought up but seems like a bad idea for several reasons. First, the database could get pretty big. This would really kill start up and shut down times, which is very important to FF users. Second, what would happen if we crash?
One possibility is if we think we'll be doing a lot of UI, to make an in-memory "read-only" copy of everything we will need. Writes go to both the networked file and our memory cache. It would be difficult to figure out when/how this could happen, though, and we would have to balance latency vs. the time to slurp all the data locally. Brett On 9/13/05, Eric Scouten <[EMAIL PROTECTED]> wrote: > To what extent is the database shared (either intentionally or > unintentionally)? Or, put another way, do you have an option to cache > data locally? > > Since you are restricting access to the profile to a single process at a > time, your best bet is probably to make a local copy of the DB during > the app session (you do have *some* local temporary storage, right?) and > copy that DB back to the network storage at the end of the session. > > -Eric > > > P.S. Thanks for your work on Firefox. Like SQLite, it's a great piece of > software and I'm grateful to be able to use it. > > > > 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 > >
