[EMAIL PROTECTED] wrote:
> 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.
=====
I have an answer to my own question. A little thought and searching and
I realize that a file descriptor is a per-process structure which when
used in threaded operations is made safe by serializing with a mutex.
Since the underlying file descriptors is not inherently thread safe any
connection inherits that state.
The solution I seek is to use the Sqlite shared cache capability and
figure out another way to use FTS2 or to implement a text search.
Some tests showed that short transactions, taking around 400uS provide a
high debree of concurrency without clashes, but that is luck, not a
certainty.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
