Joe Wilson 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?
My understanding is that the multi-thread contention is due to POSIX
file locks. Avoid them and replace the function with read/write locks
and the problem goes away. We are having no problems, and my perusal of
the code does not show up a potential problem, but I may have missed
something and can stand corrected by a more knowledgable person.
In software we have distributed for years we have had sporadic problems
with b-trees being broken by unreliable file locks. Early versions of
Linux even up to 2.4 had problems. Avoiding these locks whereever
possible is prudent.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
