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 skipping any polling or busy waits.
Pthreads provides all the capabilities in the API. Windows needs a
little work to implement read locks.
Jens Miltner wrote:
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]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
