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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
