Am Wed, 9 Jan 2008 10:20:31 -0800 (PST) schrieb Ken: > Definately use 3.5.4. > > Not sure how to determine at compile time if the threadsafe part is > enabled. You can always compile yourself to guarantee its set, thats > what I do. > > sqlite will lock the database file for you automatically. Your > threads do not need to implement locking. But they do need to handle > in some fashion. SQLITE_BUSY and/or SQLITE_LOCKED error codes. > > You should also look at "Begin", "Begin Exlusive" and "Begin > Immediate" sql commands.
Ok, I found the docs. But I exec only single SQL queries at the moment. So I think I don't need that. > As a user you don't get to pick the lock state, sqlite does that > automatically for you. You must handle the return codes suche as > SQLITE_BUSY, SQLITE_LOCKED etc. Now I implemented a multi-threading example that reads and writes in a database file. Currently I check return values and if in BUSY or LOCKED state I wait some time and try it again until I get the lock. It works, but currently I have around 20 BUSY operations for 5 successful write operations in 5 threads parallel threads. Is it really the way of choose to do it this way? Isn't there a way without active waiting? I would prefer exec() blocking until I get a write lock to not have to loop with a sleep until it works. regards Andreas ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------