in linux inotify - http://man7.org/linux/man-pages/man7/inotify.7.html in windows FindFirstChangeNotification/FindNextChangeNotification https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx
if you wait for an actual change before checking to see if there really was a change.... and can prevent arbitrary polling On Tue, Nov 7, 2017 at 10:07 AM, Wout Mertens <wout.mert...@gmail.com> wrote: > I'm working with a db that's only written to in transations, and each > transaction increases a db-global version counter. > > This means that I can cache all reads, unless the version changed. > > What would be the most efficient way to make sure I *never* serve stale > data? > > Right now everything's a single process, so it's really easy, just clear > the cache on every write. However, I want to be prepared for the near > future where I will have multiple processes using this db file. > > I'm thinking that to detect writes, this might be a safe approach: > > Before serving any cached read, check the timestamp on the wal file. If it > changed, read the global version. If it changed, clear the cache. > Otherwise, serve the cached read. > > Is it safe to assume that all writes would mean change of the wal file > timestamp? > More importantly, is it faster to check the timestamp or would a prepared > query for the version actually be faster (and safer)? > > Also, I'm using WAL right now, but I wonder if that's really useful given > the single-writer-at-a-time? > > Thank you for your insights, > > Wout. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
