Richard, thank you for responding to my questions about SQLite's WAL design.
Richard Hipp wrote: > We've been working on an incremental checkpointing mechanism for about a > week. With incremental checkpointing, the checkpoint can be run more or > less continuously in a background thread or process. Writers never block > readers, readers never block writers, and checkpointers never block > anybody. There can still only be one writer at a time, though, so writers > still block other writers. I look forward to this, which should be a considerable improvement that shouldn't really increase complexity. I'm not going to advocate trying to support multiple concurrent writers, which is probably where most of any complexity would lie, or not any more so than SQLite currently does. Now, another item, which I forgot to state earlier ... 4. Quoth the raven: "3. Transactions that involve changes against multiple ATTACHed databases are atomic for each individual database, but are not atomic across all databases as a set." I greatly hope that this limitation could go away. I consider that SQLite's ability to make multiple databases subject to a common transaction is very powerful, and I would even argue, essential. I hope that some variation of the method used now with rollback journals can be applied to databases with WALs, so that the latter can take part in cross-database transactions. I don't see anything in the WAL design that this couldn't be done without much complexity. Thank you in advance. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users