> Also, I see in the documentation that when shared-cache mode is enabled, > SQLite uses table-level locking (instead of the default file-locking). > Taken all together, it suggests that you can get table-level locking > *and* write-ahead logging *and* atomic multi-table commits -- all within > a single file -- simply by enabling shared cache mode.
Beware that shared cache mode turns on table-level locking only inside one process between several connections. Inter-process locking is still file-level. Also beware that in shared cache mode all connections to the same database share one mutex on the cache, so all calls to sqlite3_step on all connections to the same database will be effectively serialized. Pavel On Tue, Aug 10, 2010 at 2:45 PM, David Barrett <dbarr...@expensify.com> wrote: > On 08/08/2010 10:09 PM, Dan Kennedy wrote: >>>> 2) However, one process cannot read from the database while another >>>> is writing -- WAL is irrelevant here. >>> >>> Unless shared-cache mode is turned on, multiple threads each using >>> their own sqlite3* connection should behave in the same way as >>> multiple processes do wrt to sqlite locking. >> >> I should be clearer: The above was meant to imply that (2) >> is not a true statement. The others are all correct. > > Very interesting! To confirm I understand, if shared-cache mode is > enabled, then one process can read while another process is writing. > > Also, I see in the documentation that when shared-cache mode is enabled, > SQLite uses table-level locking (instead of the default file-locking). > Taken all together, it suggests that you can get table-level locking > *and* write-ahead logging *and* atomic multi-table commits -- all within > a single file -- simply by enabling shared cache mode. > > Am I reading this correctly, or does shared-cache table-level locking > still require that each table be put in different files as described here: > > http://www.sqlite.org/version3.html > > (If so, then it means the only way to get table-locking with WAL is to > put the tables in different database files, but then WAL "disadvantage > #3" says you lose atomicity.) > > Thanks Dan, I really appreciate your help! > > -david > _______________________________________________ > 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
