Re: [sqlite] High performance and concurrency

On 2 March 2018 at 03:43, Shevek wrote: > We use HikariCP, so a connection is in use by one thread at a time with > JMM-safe handoff, and they all share the mmap region. > Shevek also wrote: > What I think is happening is that either a pthread mutex or a database lock is

Re: [sqlite] High performance and concurrency

Shevek wrote: > Why would I have a transaction of non-zero size on a read-only connection? What do you mean with "size"? A read-only transaction still puts a shared lock on the database file. A read-only transaction will not change the DB file, but SQLite has lots of internal data structures in

Re: [sqlite] High performance and concurrency

Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Shevek Gesendet: Donnerstag, 01. März 2018 09:10 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>; Simon Slavin <slav...@bigfraud.org> Betreff: [EXTERNAL] Re: [

Re: [sqlite] High performance and concurrency

On 02/28/2018 11:45 PM, Simon Slavin wrote: On 1 Mar 2018, at 7:24am, Shevek wrote: What I think is happening is that either a pthread mutex or a database lock is serializing the accesses, so each thread blocks the others. To be specific, I'm concerned about is the

Re: [sqlite] High performance and concurrency

On 1 Mar 2018, at 7:24am, Shevek wrote: > What I think is happening is that either a pthread mutex or a database lock > is serializing the accesses, so each thread blocks the others. What journal mode are you using ?

[sqlite] High performance and concurrency

Hi, I would like to have truly concurrent access to an sqlite database, that is, the ability for multiple connections to read from the database simultaneously. I'm using Java with xerial's sqlite-jdbc, customized to let me mmap the entire database into RAM, and with additional debugging