On 7/27/07, John Stanton <[EMAIL PROTECTED]> wrote: > Scott Hess wrote: > > On 7/26/07, Richard Klein <[EMAIL PROTECTED]> wrote: > >>According to the Mozilla article referenced above, it's even worse than > >>that: *All* cache pages, dirty or not, are freed at the end of *every* > >>transaction, even if the transaction consisted of only read operations. > > > > I believe this is no longer true, as of a couple months ago. Now > > SQLite tracks whether any other database connection has written data, > > and doesn't invalidate the pages if nobody else is writing. > > > > I think this is completely orthogonal to shared cache. > > A few questions: > o Is this behaviour general or just in shared cache mode? You imply > that it is the general case. > o If it is general, how does it detect a stale cache? By an indicator > on the file?
The sqlite changes list has the following back in April: > Do not flush the page cache (and thus avoiding a cache refill) > unless another process changes the underlying database file. My understanding is that writes to the database increment a counter somewhere, and after getting the shared lock readers can check that counter to see if they can continue using their existing cache or not. I think the writer knows to increment both counters, so if you only have one writer it doesn't have to flush (one writer with many readers would flush the reader's caches). This is the general case. I don't know how it impacts shared cache mode, but I would _imagine_ that the shared cache would operate the same way. I've not used shared cache mode anywhere, though, so my opinion really is in the realm of imagination :-). -scott ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
