Re: [sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection pool?

2018-03-27 Thread Jens Alfke
> 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

Re: [sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection pool?

2018-03-27 Thread Olivier Mascia
> 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

Re: [sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection pool?

2018-03-27 Thread Keith Medcalf
>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

[sqlite] SQLITE_CONFIG_MULTITHREAD needed for connection pool?

2018-03-27 Thread Deon Brewis
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: