> one thread is preparing an "INSERT" statement (It returns SQLITE_OK), > then it is executed using sqlite3_step. sqlite3_step returns an > SQLITE_BUSY! Is there any possibility for this?
Sure. Preparing INSERT statement doesn't acquire any "write" locks on the database. It's executing the INSERT statement that acquires locks. So if while executing statement finds that it can't get the locks then sqlite3_step returns SQLITE_BUSY. And thread-safety is irrelevant here. Pavel On Wed, Jul 7, 2010 at 7:56 AM, Lloyd <ll...@cdactvm.in> wrote: > Hi, > > We have a multi-threaded application (I know "threads are evil", but this is > a small server application). Each thread tries to access the SQLite database. > When trying to get a DB handle (sqlite3_open), if it returns SQLITE_BUSY, > then the thread will wait for some time and try to open it again (until it > gets the handle). In our case, two threads are running, one thread is > preparing an "INSERT" statement (It returns SQLITE_OK), then it is executed > using sqlite3_step. sqlite3_step returns an SQLITE_BUSY! Is there any > possibility for this? ( I think these two threads are obtaining the DB handle > at the same time using sqlite_open - with wrtie permission- is it possible?) > I have tried compiling the application with both -DSQLITE_THREADSAFE=2 and > -DSQLITE_THREADSAFE=1. > > Any hint would be very helpful... > > Thanks a lot, > Lloyd > > ______________________________________ > Scanned and protected by Email scanner > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
