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
