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
