Quote: "This is the effect if you use BEGIN IMMEDIATE instead of just BEGIN"
BEGIN IMMEDIATE will start a write transaction, which will block other writers with SQLITE_BUSY until its complete. 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" On Tue, Jul 30, 2019 at 8:23 PM Simon Slavin <slav...@bigfraud.org> wrote: > On 30 Jul 2019, at 6:44pm, test user <example.com.use...@gmail.com> wrote: > > > I am using `journal_mode=WAL`. > > > > What I am trying to do: > > > > From the first `BEGIN` that returns `SQLITE_OK`, all SELECTs read from > the same snapshot/point in time. > > This is the effect if you use BEGIN IMMEDIATE instead of just BEGIN. So > do BEGIN IMMEDIATE, then as many SELECTs as you want, then END. For the > duration of that transaction, all your SELECTs will reflect the same > snapshot of the database. > > > The issue is that its hard to tell if I reading from a read snapshot > (where any successful commit on other connections since the reads BEGIN are > ignored). > > Depending on various things, other connections trying to change the > database will be blocked (locked out of making changes), or will make > changes that will not be 'seen' by the above transaction. > _______________________________________________ > 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
