RE: [sqlite] More SQLite Misuse, sorted i think
> Hope that is more clear. Perfectly. I get it now. As you say in the other post, every sqlite call needs to be inside the critical section, including sqlite3_finalize(). Dan. - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] More SQLite Misuse, sorted i think
In my sample that I supplied I illustrated how two threads does the following: Lock (Global Critical Section) Queryobject.Prepare (Sqlite3_prepare) QueryObject.Step (Sqlite3_step) QueryObject.Reset (Sqlite3_reset) Unlock QueryObject.Free; (Sqlite3_reset (the missing piece of the puzzle)) In the above example the call to these 3 functions are locked in a global critical section, so none of them can be executed at the same time, however: The last line of code I did not see I had an object that was destroyed that called sqlite3_reset. This is where the problem lied, the destructor of the object did something as follows: Destructor If FHandle <> nil then begin Sqlite3_reset; Sqlite3_finalize; FHandle := nil; end I understand that the call to sqlite3_reset is a bit pointless in the destructor here as Sqlite3_finalize takes care of all that, but it is just interesting to note that by the removal of sqlite3_reset OR by locking the call to sqlite3_reset it seemed to work, however locking the call to sqlite3_finalize did not seem to be necessary and did not produce the SQLITE_MISUSE error. Hope that is more clear. -Original Message- I'm not sure I completely understand, but anyway... :) - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] More SQLite Misuse, sorted i think
Sorry if I created any confusion there were some code that seemed to have called Sqlite_reset simultaneously from more than one thread, even though the statements were unique for each thread the call to the library was not locked. I know assumptions are bad but I thought that reset on a unique statement should not have to be locked and serialized, but now I think it might, so now every single call to the library gets locked in a critical section and it seems to work. However finalize worked because it seems that finalize can be called without synchronizing. -Original Message- From: Andre du Plessis [mailto:[EMAIL PROTECTED] Sent: 19 June 2007 07:21 PM To: sqlite-users@sqlite.org Subject: [sqlite] More SQLite Misuse DLL version Sqlite3.3.17 The os is windows After the last query of sqlite3_step I decided to so some more tests, with threads, if synchronized properly, it seems that you can use more than one thread without any problem as long as Sqlite3_finalize is called is this correct? Please note that this is a very simple query being executed : "select * from threads where id = 1" Imagine in the following scenarios both threads are executing simultaneously and will lock on the global critical section (so they are synchronized) Using the same DB handle. Scenario 1 THREAD1 THREAD2 LockGlobalCriticalSection LockGlobalCriticalSection Sqlite3_prepare Sqlite3_prepare Sqlite3_step Sqlite3_step< SQLITE_MISUSE: library routine called out of sequence here Sqlite3_reset Sqlite3_reset UnLockGlobalCriticalSection UnLockGlobalCriticalSection // The following code works fine though THREAD1 THREAD2 LockGlobalCriticalSection LockGlobalCriticalSection Sqlite3_prepare Sqlite3_prepare Sqlite3_step Sqlite3_step Sqlite3_finalize Sqlite3_finalize UnLockGlobalCriticalSection UnLockGlobalCriticalSection If my tests are correct it is not possible to retain a prepared statement across threads. And has to be reprepared each time ?? - To unsubscribe, send email to [EMAIL PROTECTED] -
