Allen wrote: > 1. It would be nice to have read-only transactions for use with WAL > databases. When a read-only transaction was started, it would take a > "lock" on the WAL and then not advance further into the WAL until the > transaction ended. Thus, all select statements issued while the read > transaction was open would see all writes that had been committed prior to > the start of the read transaction, but would not see any writes that are > not yet committed when the read transaction is started or writes that start > or complete while the read transaction is open. This would apply to all > (multiple) select statements that would all see the same view of the data > during the duration of the read transaction.
How is this different from a normal transaction? > 3. It would be nice if there were an in-memory mode for WAL databases that > could be shared by multiple database connections on multiple threads (or > possibly multiple processes) and that had the benefits of "multi-version > concurrency" but the data was kept entirely in memory You could create your own VFS for that. (While WAL allows _some_ concurrency, SQLite is not really designed for high concurrency.) Regards, Clemens
