SELECT is read only. Think of an Sqlite lock as a lock on the journal
file. The critical action of an Sqlite insert or update is to transfer
the contents of the journal file to disk and verify that the write to
disk has completed (the ACID feature). Apart from that it is read only.
I'd like to use reader-writer lock in the client code, but at this point
I'm not sure if I can determine at which point SQLite is not writing.
I mean, INSERT / UPDATE are most likely need a writer lock, but I
don't know if SELECT is guaranteed to be read-only in its internal
operation within
Using read and write locks around your statements gives you protection
and lets you compile without thread safe so that Sqlite does not use
internal mutexes as much for synchronization saving you considerable
overhead as well as avoiding the logic necessary to handle BUSYs from
Sqlite and
Am 19.1.08 um 03:13 schrieb [EMAIL PROTECTED]:
OK I figured out SQLITE_THREADSAFE=0 for the second question...
And it seems the answer for the first question is yes, but if you know
a simpler way please share it with us, thanks!
You could use a read-write mutex to serialize access to your
OK I figured out SQLITE_THREADSAFE=0 for the second question...
And it seems the answer for the first question is yes, but if you know
a simpler way please share it with us, thanks!
-- sword
On Sat, 19 Jan 2008 09:57:10 +0900
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've
Hello all,
I've read http://www.sqlite.org/lockingv3.html but am still not sure about
multithread and locking in 3.5.4.
I have a multithread application that has a single connection to a single
SQLite3 database. Since it's multithreaded, SQL statements are thrown to
a single SQLite3 object
6 matches
Mail list logo
