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 database
connection. That way you can have multiple readers, but modifying the
database becomes an exclusive operation. This matches the sqlite
requirements.
Alternatively, you can just retry your write queries if you get
SQLITE_BUSY errors...
-- sword
On Sat, 19 Jan 2008 09:57:10 +0900
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
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 concurrently. I'm using
http://www.sqlite.org/sqlite-amalgamation-3_5_4.zip
on VC8 + WindowsXP.
Prior to this version (I was using SQLite2) I'd serialized all
these database access
using critical sections and didn't care about SQLITE_BUSY or
SQLITE_LOCKED
since they never happen. It was very simple as I didn't need to
implement access
retry for a busy case.
However, I learned that SQLite 3.5 does mutexing by default. So I
removed
all synchronization stuff in my SQLite access code, and now it seems
it's not working as I intended. Unfortunately I can't reproduce it
in my
development environment and I've not yet implemented logging to see
if it's due to SQLITE_BUSY or SQLITE_LOCKED. I saw it's entering
sqlite3_mutex_enter multiple times in the debugger though, so it's
thread-safe
at least.
My question is,
1. Do I still have to synchronize all SQLite access in my client
code not to
encounter SQLITE_BUSY or SQLITE_LOCKED? (Or is there any better way?)
2. If so, how can I turn off all these mutexes (critical sections)
in SQLite 3.5.4?
They are needless if I serialize all SQLite access in the client
code.
Regards,
-- sword
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------