On 7/30/19 5:33 PM, Olivier Mascia wrote: >> Le 30 juil. 2019 à 22:39, test user <example.com.use...@gmail.com> a écrit : >> >> What I would like is something like BEGIN READ, which will not block >> writers for its duration. >> >> This "read transaction" can see all committed transactions that happened >> before it, but none after it. >> >> At the moment it seems to get this guarantee I will need to do a "BEGIN; >> SELECT * from sqlite_master LIMIT 1" > I would drop the "SELECT * from sqlite_master LIMIT 1" or whatever other > dummy read. As long as your explicit transaction, started with "BEGIN" which > is a shortcut for "BEGIN DEFERRED", does not actually start reading anything, > what importance does it have for you that it already holds an "end-mark"? > (See link below for reference to the "end mark" concept). As soon as it > reads anything, it will see the database from that point on, until ROLLBACK > or COMMIT, as it was at point of that single first read. > > https://www.sqlite.org/wal.html#concurrency IF the only interaction the program has with other parts is via the database, then yes, it shouldn't be important exactly when the program 'locks' it view of the database. On the other hand, if there might be other communication channels open, then it might be important that the program has at a particular point before it really needs to access the database that it establish its 'end-mark'. Doing the SELECT is one way to do that, adding some variation of BEGIN that immediately starts a SHARED lock would be another.
-- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
