[EMAIL PROTECTED] wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
--- John Stanton <[EMAIL PROTECTED]> wrote:
Using a single Sqlite connection for each database and holding the
connection open means that maximum effect is obtained from Sqlite's
cache. As far as we can ascertain avoiding fcntl removes any issues
regarding multiple threads accessing a single connection.
I did not know that a single sqlite3 connection could be used
concurrently by readers from multiple threads.
Previous postings on this list suggested that although an sqlite3
connection could be passed from thread to thread (as is common in
a connection pool scenario), only one thread may use that connection
at a given time.
Can the SQLite authors confirm that simultaneous use of a single
connection by multiple reader threads is supported without external
mutexes?
A single connection can only be used by a single thread at
a time. If you have multiple threads running at the same
time, they each need to have their own connection.
If you are not running on a Linux 2.4 kernel, then you can
pass connections from one thread to another. So thread A
can do a little work, then hand the connection of to
thread B to continue. But thread A and thread B should not
try to use the same connection at the same time.
The reason for this should be obvious. A "connection" is
a structure, with various fields holding state information.
Each SQLite API call expects the connection to be in a
consistent state when it is first invoked and each API call
leaves the connection in a consistent state when it returns.
But while the API is running, the structure can be in various
transient states that are not strictly "consistent". We cannot,
after all, make multiple changes to a structure atomically
on real hardware. If two threads try to modify the same
structure at the same time, they will be seeing each others
inconsistent transient state and chaos will ensue.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Thankyou for the explananation. A further quaestion. When an Sqlite
thread is performing a read (SELECT) what elements of the shared
structure are being altered? In other worlds what needs to be thread
local or single streamed to make a read thread safe for reading?
You probably see what I am getting at. The aim is to share a single
cache between all users. The shared cache option has some limitaions
which are ideally avoided.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
