I think what he's saying is "my reads are slow, and I don't want them to block my writes" which would mean he <should> use WAL mode.
i.e. the long reads are going to cause a traffic jam of backed up writes in rollback journal mode, but will be ok in WAL mode. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Tuesday, August 07, 2018 12:56 PM To: SQLite mailing list Subject: Re: [sqlite] Database locks On 7 Aug 2018, at 3:04pm, Gerlando Falauto <gerlando.fala...@gmail.com> wrote: > What might happen in my case is that reads could take a very long time to > consume/process all the data (30s for instance), and I believe the lock is > held until all data is consumed. > I believe in that case the read would see all the data up to the point in > time when the SELECT was first issued, ignoring whatever happened later, is > that right? If your writes are fast, and your reads are slow, you should not use WAL mode. Just set a good long timeout on both connections and let SQLite do its thing. A sixty second timeout should be about the minimum you should set, since you wouldn't want your program to crash for anything less than that. Simon. _______________________________________________ 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
