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
>
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
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
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
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
> "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
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.
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:
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
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.
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
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
>
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.
13 matches
Mail list logo