On Monday, 18 April, 2016 08:47 Olivier Mascia wrote:
> Just to clarify: you mean compiled using SQLITE_CONFIG_MULTITHREAD (and > not SQLITE_CONFIG_SERIALIZED), is that it? > Then, if using threads in the application, each thread has its own > connection (or multiple connections) but no thread share any connection > with another one? (This is required for SQLITE_CONFIG_MULTITHREAD mode, > else you would need SQLITE_CONFIG_SERIALIZED, and that would add a lot of > contention). You do not have to restrict a connection to a thread, and you can use the same connection from multiple threads. What you cannot do (and what SERIALIZED enforces) is that only one thread per connection can be executing inside (entered) the SQLite engine/library at a time. That is, a connection (and anything derived from that connection) is fully serially entrant across threads. It is not, however, multiply entrant. The only difference between MULTITHREADED and SERIALIZED is that in the latter case SQLite enforces single entrance per connection -- in MULTITHREAD you have to enforce that yourself. Dedicating a connection per thread and having a given thread only use its connection is one way of enforcing the single entrance requirement, but not the only way.
