> On Mar 27, 2018, at 2:37 PM, Olivier Mascia wrote:
>
> Been there, changed plans. In our case we profiled no net benefit from such
> a pooling compared to have each thread which need a connection to actually
> open it, use it and then close it. It looks like you really
> Le 27 mars 2018 à 22:55, Deon Brewis a écrit :
>
> The model we use for SQLITE is to use a connection pool (connections opened
> via sqlite3_open_v2).
>
> We have many threads, but only one thread can use a connection at a time - a
> thread takes it out of the pool, and
>Subject: [sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection
>pool?
>
>The model we use for SQLITE is to use a connection pool (connections
>opened via sqlite3_open_v2).
>
>We have many threads, but only one thread can use a connection at a
>time - a thread takes it
The model we use for SQLITE is to use a connection pool (connections opened via
sqlite3_open_v2).
We have many threads, but only one thread can use a connection at a time - a
thread takes it out of the pool, and when done, returns it to the pool.
The only exception to this is calls to:
4 matches
Mail list logo