Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Boris Kolpackov
Hi Marc, "Marc L. Allen" writes: > If I understand correctly, the purpose of the overall mutex is to prevent a > page from being removed underneath a user. If the standard DB locking > semantics are working properly, I think there is no possibility of a page's >

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Boris Kolpackov
Hi Pavel, Pavel Ivanov writes: > > "There are four levels to the shared-cache locking model: transaction > > level locking, table level locking, cache level locking, and schema > > level locking. They are described in the following three sub-sections." > > This would be a

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Marc L. Allen
Discussion of SQLite Database Subject: Re: [sqlite] Multi-Thread Reads to SQLite Database On 13 Aug 2012, at 3:11pm, Marc L. Allen <mlal...@outsitenetworks.com> wrote: > I wonder if it would be possible to refine the cache locking mechanism. > > If I understand the modified DB/Table lo

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Simon Slavin
On 13 Aug 2012, at 3:11pm, Marc L. Allen wrote: > I wonder if it would be possible to refine the cache locking mechanism. > > If I understand the modified DB/Table locking semantics when running under a > shared-cache, it appears that the cache page should be

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Marc L. Allen
I wonder if it would be possible to refine the cache locking mechanism. If I understand the modified DB/Table locking semantics when running under a shared-cache, it appears that the cache page should be protected against readers and writers. Perhaps only the list of pages in the cache need to

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Pavel Ivanov
> "There are four levels to the shared-cache locking model: transaction > level locking, table level locking, cache level locking, and schema > level locking. They are described in the following three sub-sections." This would be a bad way of documenting this because "cache level locking" works

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Pavel Ivanov
Another idea for you: > In our test, on the other hand, each thread queries its own set of > rows from the table. So, based on your explanation, here each thread > should end up with its own set of pages (more or less). However, even > in this case, I still observe a near sequential performance.

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Boris Kolpackov
Hi Richard, Richard Hipp writes: > In shared-cache mode, SQLite acquires a mutex on the shared cache, thus > serializing access. Oh, that's quite a surprise. I would have never said that something like this is going on just by reading the documentation page on shared cache:

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Marc L. Allen
Of Boris Kolpackov Sent: Monday, August 13, 2012 8:51 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Multi-Thread Reads to SQLite Database Hi Richard, Richard Hipp <d...@sqlite.org> writes: > In shared-cache mode, the page cache is shared across threads. That > means that each

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Richard Hipp
On Mon, Aug 13, 2012 at 8:51 AM, Boris Kolpackov wrote: > > Also, your explanation doesn't feel quite satisfactory to me. > In shared-cache mode, SQLite acquires a mutex on the shared cache, thus serializing access. The mutex is acquired because it is usually needed.

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-13 Thread Boris Kolpackov
Hi Richard, Richard Hipp writes: > In shared-cache mode, the page cache is shared across threads. That means > that each thread must acquire a mutex on the page cache in order to read > it. Which means that access to the page cache is serialized. I just ran our concurrency

Re: [sqlite] Multi-Thread Reads to SQLite Database

2012-08-10 Thread Richard Hipp
On Fri, Aug 10, 2012 at 12:18 PM, esum wrote: > > However, when I ran this same test with SQLITE_OPEN_READWRITE | > SQLITE_OPEN_SHAREDCACHE for the flags, I get the following [slower] > results: > > Why am I seeing such a high increase in times as I add threads in shared >

[sqlite] Multi-Thread Reads to SQLite Database

2012-08-10 Thread esum
way to fix this and still use shared cache mode? Thanks for any help. It is much appreciated. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Multi-Thread-Reads-to-SQLite-Database-tp63697.html Sent from the SQLite mailing list archive at Nabble.