On Tuesday, 30 July, 2019 13:01, test user <example.com.use...@gmail.com> asked:
>How sure are you that "any SELECT that reads from the DB file starts >a read transaction"? Well, it is not that it starts a transaction so much as it acquires a shared lock. You cannot read data from a database file without first having acquired a shared lock. >Does the read transaction read from a snapshot of the entire DB, or >are only specific tables in the read snapshot? "Snapshot" is a misnomer. What you get is point-in-time repeatable read isolation. Since the database can only be updated as a whole the repeatable-read applies to the entire database. Technically, all "read transactions" are repeatable read isolation, since you cannot update the database while a shared (read) lock is held by another connection. WAL simply permits a writer to proceed despite concurrently held shared locks by "holding off" updating of the actual database file until after the shared lock is released by writing the data to a "differences" file. Behaviour may, of course, be different if you are using "simulated locking" such as shared-cache, which "simulates" locking at a table level amongst connections to the same shared-cache. The single connection from the shared-cache to the database uses the normal "whole database file" locking and update semantics. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
