On 29 Nov 2016, at 6:10pm, Mark Hamburg <mhamburg...@gmail.com> wrote:
> In the single WAL scenario, what I probably really want is a way for the > checkpoint operation on the write connection to do its work then wait for > exclusive access — standard reader/writer lock pattern — to do the WAL reset. > This would presumably limit the time that the readers were blocked since I > would expect the WAL reset to be reasonably quick if the checkpoint copying > work were already complete. Remember that SQLite has no server or background processes. All your processes are messing with the database file in real time while the SQLite API calls are executing. > Furthermore, the write operation would only be blocked for the length of the > longest outstanding read so as long I favor big transactions for writes and > short queries for reads, the writer shouldn't be blocked for too long either. > Are there checkpoint settings that achieve this or do I need to build that > logic into my code? You can use the SQL command "BEGIN IMMEDIATE". That’s quite standard and is no problem. You can also use "sqlite3_db_mutex()". This is non-standard and you need to understand exactly what you’re doing. But given how good SQLite is at this stuff itself (really really good) you’re unlikely to be able to improve on SQLite’s default behaviour. You can spend 100 hours programming and end up with something no better than if you’d done nothing. So I strongly recommend you leave stuff alone and let SQLite do it’s thing. But if you really want to mess with it, that’s how. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
