I respectfully disagree with the reader/writer concurrency based upon the
test_server.c model. The server thread executes each request independently and
serially. The requests may be intermingled but they are not concurrently
executed.
Maybe my definition of conccurency is different,
A and B are executing on two seperate CPU's at the same time. ie each is
calling sqlite3_step to select/write data. But to my understanding this is
explicitely disallowed by sqlite as well as the test_server.c architecture.
Maybe I'm missing something here? Please help me see were I can gain
concurrency using the shared cache.
Thanks,
Ken
Ken <[EMAIL PROTECTED]> wrote:I found part of the issue, in switching servers
around the test version did not enable the shared cache... My fault.. however I
still recieved a RC 5 on a different write operation.
Modifed the test_server code to repost the step and all was well. A better
solution however is to cause the server to filter, based upon the thread id's
this saves a small amount of time due to not recalling the sqlite3 functions
just to get another server is locked message.
Ken wrote:
I ran everything through the test_server "server" and get the following
results when using read_uncommitted=1
rc=[5] msg=[database is locked]
when performing a "client_step" against a prepared select
statement.
I'd really like to track this down and find out if my code is incorrect or if
I've hit a bug.
Thanks,
Ken
[EMAIL PROTECTED] wrote: Ken wrote:
>
> My thought was that if i wanted to perform selects concurrently on SMP
> system I would need 2 threads and each thread would be able to read
> concurrently....
>
> I just don't see how this [test_server.c] improves concurrency...
>
It improves write concurrancy. One client can read from table A
at the same time another client is writing to table B. Or if
read_uncommitted is turned on, one client can read from table A
at the same time that another client is writing to th e same table.
--
D. Richard Hipp
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
[EMAIL PROTECTED] wrote: Ken wrote:
>
> My thought was that if i wanted to perform selects concurrently on SMP
> system I would need 2 threads and each thread would be able to read
> concurrently....
>
> I just don't see how this [test_server.c] improves concurrency...
>
It improves write concurrancy. One client can read from table A
at the same time another client is writing to table B. Or if
read_uncommitted is turned on, one client can read from table A
at the same time that another client is writing to th e same table.
--
D. Richard Hipp
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
