OK, thank you all for your support.
On Thu, Jun 26, 2014 at 3:22 AM, Igor Tandetnik <i...@tandetnik.org> wrote: > On 6/25/2014 8:48 PM, João Ramos wrote: > >> Now that you mentioned the WAL, shouldn't this actually help prevent this >> scenario? >> > > Quite the opposite - WAL helps enable this scenario. With traditional > rollback journal, the writer would be unable to write at all while a reader > is active, so issues of visibility fail to arise. Thus, as long as at least > one connection to the shared cache has an open statement, so does the > cache's connection to the underlying file, and the writer will be locked > out. > > > I've never looked at SQLite implementation, but if a transaction >> starts after a successful commit (T1), the new data it tries to access >> shouldn't be cached because it was just now written to the WAL, correct? >> > > Yes. But remember - this is true for "real" connections to the underlying > file. All "pseudo"-connections to the shared cache use the same underlying > "real" connection. The transaction on the "real" connection starts when the > number of "pseudo" transactions on "pseudo" connections goes from 0 up to > 1, and ends when that number goes from 1 down to 0. > > -- > Igor Tandetnik > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
