> Le 6 août 2019 à 12:34, test user <example.com.use...@gmail.com> a écrit : > > So for example, if I had: > > - 8 cores > - 8 threads > - 8 db connections, 1 per thread > - 1 database file > - x amount of read requests per second > > If I were to load balance x requests over each of the 8 threads, all the > reads would complete concurrently when in SERIALIZED mode, with WAL enabled?
Yes. Also, if your software can guarantee, by its own design, that a db connection (and its dependencies, aka statements) will never ever be shared by multiple threads, (or other techniques like fibers in Windows for instance), you don't need the per connection mutex that SERIALIZED brings to you, and you can use MULTITHREADED. But you can't run in SINGLETHREAD mode from a multi-threaded process. > Im just trying to confirm that SERIALIZED will not queue up requests for (1 > file, multiple connections to that file, read only requests). The SERIALIZATION in question here is a per connection (- data structures) matter. It isn't related to the concurrency of accesses to the db through distinct connections. But you do need WAL to achieve multiple readers concurrency, each in a BEGIN [DEFERRED] [TRANSACTION] which you will take care not to upgrade inadvertantly to a writer (by executing any statement which would imply writing to the database). Each of the readers will see a stable view of the database content, as of their first read statement after BEGIN. And this will last until they COMMIT (or ROLLBACK as they are anyway supposed to be readers). If not using explicit transactions, each statement will run independently in an auto BEGIN [DEFERRED] / auto COMMIT transaction. — Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit besten Grüßen, Olivier Mascia _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
