> Thanks for clarification. I assumed the error message of error code > SQLITE_BUSY is something like "databased is busy".
http://www.sqlite.org/c3ref/c_abort.html Also in sqlite3.h file - comments on the right are almost exactly reflect the corresponding error message. > Another newbie question. Is it safe for 2 threads to share 1 connection when > the connection is protected by my own mutex? Sure, everything protected by mutex can be considered executing in one thread and thus is never prone to multi-threading issues. Pavel On Wed, Mar 17, 2010 at 3:00 PM, imin imup <imini...@gmail.com> wrote: >> According to documents, sqlite_busy will happen if new reader cannot get > >> > shared_lock or new writer cannot get reserved_lock. >> > I didn't see sqlite_busy error from my application. >> >> I didn't understand this. "database is locked" is SQLITE_BUSY. >> > Thanks for clarification. I assumed the error message of error code > SQLITE_BUSY is something like "databased is busy". > >> >> > Does this mean I need to close the current database connection before I >> can >> > make the next connection to same database file even through they are not >> > shared? >> >> No, you can have several connections in one thread if you want. >> >> > Though it is not shared, it seems there may be cases where more >> > than 1 database connections are held (in nested function calls). Will >> this >> > cause any issue? >> >> This can definitely be the issue. Consider this scenario: >> - open connection 1; >> - start executing some query on connection 1 - call sqlite3_step() but >> it didn't return SQLITE_DONE yet; >> - open connection 2; >> - execute some update/insert/delete on connection 2 >> >> In this case you have active statement on connection 1 that holds >> SHARED lock on the database. And it will prevent any other connections >> from writing. So connection 2 cannot obtain EXCLUSIVE lock, you get >> SQLITE_BUSY without any chances to succeed. >> > > Very good point. It seems one connection per function can be error prone. > One long-lived connection per thread might be better. > > Another newbie question. Is it safe for 2 threads to share 1 connection when > the connection is protected by my own mutex? > > Thanks a lot. > > >> >> Pavel >> >> On Wed, Mar 17, 2010 at 1:35 PM, imin imup <imini...@gmail.com> wrote: >> > Thanks for help. As a novel sqlite user, it seems I need more. >> > >> > According to documents, sqlite_busy will happen if new reader cannot get >> > shared_lock or new writer cannot get reserved_lock. >> > I didn't see sqlite_busy error from my application. >> > >> > My usage is that: >> > single process, multi-thread, multi-database files >> > >> > multi-database files >> > I divided the tables into 2 database files to "increase" concurrency. A >> > thread may open two database file at same time, but two database never >> > appear in one sql statement. Is this likely to cause any issue? >> > >> > about "one connection per thread" >> > Does this mean I need to close the current database connection before I >> can >> > make the next connection to same database file even through they are not >> > shared? >> > I tend to use short-lived database connections locally defined within >> each >> > function. Though it is not shared, it seems there may be cases where more >> > than 1 database connections are held (in nested function calls). Will >> this >> > cause any issue? >> > >> > On Wed, Mar 17, 2010 at 11:05 AM, Pavel Ivanov <paiva...@gmail.com> >> wrote: >> > >> >> http://www.sqlite.org/faq.html#q5 >> >> http://www.sqlite.org/lockingv3.html >> >> >> >> Pavel >> >> >> >> On Wed, Mar 17, 2010 at 11:46 AM, imin imup <imini...@gmail.com> wrote: >> >> > Hello users, >> >> > >> >> > I'm using sqlite 3.6.12 in muti-threaded application. I'm getting >> sqlite >> >> > errors occasionally. >> >> > The error message is >> >> > >> >> > *sqlite error: database is locked* >> >> > >> >> > could someone explain to me what happened and what to be done? or >> point >> >> me >> >> > to a document on how to fix this? >> >> > >> >> > Best >> >> > >> >> > Imin >> >> > _______________________________________________ >> >> > 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 >> >> >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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
