--- John Stanton <[EMAIL PROTECTED]> wrote:
> I think that you misunderstood the shared cache description. Cache is
> shared by many connections but connections may not be passed between
> threads. Each thread must maintain and use its its own connection. In
> our case a thread has an associated control block and the connection
> handle resides there.
>
> As long as you only access the Sqlite connection from the thread which
> created it you share the cache and it works fine.
The cache is only shared for all connections created and used on the same
thread. See point 2 below from test_server.c.
You seem to confused with point 1, which is just a tangential comment
regarding a certain platform, rather than a condition on the actual sharing
of the cache.
You have to use an asynchronous model to take advantage of the shared cache.
"Client" threads can post messages to the one designated "server" thread
which may process requests on their behalf via one or more connections
created and used on that server thread.
** This source file demonstrates how to use SQLite to create an SQL database
** server thread in a multiple-threaded program. One or more client threads
** send messages to the server thread and the server thread processes those
** messages in the order received and returns the results to the client.
**
** One might ask: "Why bother? Why not just let each thread connect
** to the database directly?" There are a several of reasons to
** prefer the client/server approach.
**
** (1) Some systems (ex: Redhat9) have broken threading implementations
** that prevent SQLite database connections from being used in
** a thread different from the one where they were created. With
** the client/server approach, all database connections are created
** and used within the server thread. Client calls to the database
** can be made from multiple threads (though not at the same time!)
**
** (2) Beginning with SQLite version 3.3.0, when two or more
** connections to the same database occur within the same thread,
** they can optionally share their database cache. This reduces
** I/O and memory requirements. Cache shared is controlled using
** the sqlite3_enable_shared_cache() API.
**
** (3) Database connections on a shared cache use table-level locking
** instead of file-level locking for improved concurrency.
**
** (4) Database connections on a shared cache can by optionally
** set to READ UNCOMMITTED isolation. (The default isolation for
** SQLite is SERIALIZABLE.) When this occurs, readers will
** never be blocked by a writer and writers will not be
** blocked by readers. There can still only be a single writer
** at a time, but multiple readers can simultaneously exist with
** that writer. This is a huge increase in concurrency.
**
** To summarize the rational for using a client/server approach: prior
** to SQLite version 3.3.0 it probably was not worth the trouble. But
** with SQLite version 3.3.0 and beyond you can get significant performance
** and concurrency improvements and memory usage reductions by going
** client/server.
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
