Thanks Richard for your reply. Actually, we have written a windows application which uses four threads. Each thread may have to add/delete thousands of entries in the database( for performance reason , we don't want to open/close the database for each insertion/deletion) .If we use different sqlite_open handle for each thread , then one thread has to do busy looping until other threads complete their operation, which is not desirable according to the application requirement. That's why we opened global database handle for the lifetime of the application and each thread used the handle serially and it worked.
Thanking you again, Roushan On Fri, 2005-07-15 at 17:57, D. Richard Hipp wrote: > On Fri, 2005-07-15 at 16:41 +0530, Roushan Ali wrote: > > Hello all, > > Can we use single sqlite_open handle(global) across threads( > > if all database operations are serialized by using semaphore) ? Please > > help. > > > > Opening a database connection in one thread and using it in another > will work on some operating systems but not on others. You are > advised not to do it. See http://www.sqlite.org/cvstrac/tktview?tn=1272 > and http://www.sqlite.org/cvstrac/chngview?cn=2521. > > Actually, this seems like a good opportunity to repeat my > oft-ignored advice to not use more than one thread in a single > address space. If you need multiple threads, create multiple > processes. This has nothing to do with SQLite = it is just > good programming advice. I have worked on countless multi- > threaded programs over the years, and I have yet to see a > single one that didn't contain subtle, hard to reproduce, > and very hard to troubleshoot bugs related to threading issues. > > I am constantly amazed at the prevailing idea (exemplified > by Java) that software should be strongly typed and should > not use goto statement or pointers - all in the name of > reducing bugs - but that it is OK to use multiple threads > within the same address space. Strong typing helps prevent > only bugs that are trivially easy to locate and fix. The > use of goto statements and pointers likewise results in > deterministic problems that are easy to test for and > relatively easy to track down and correct. But threading > bugs tend to manifest themselves as timing-dependent > glitches and lock-ups that are hardware and platform > dependent, that never happen the same way twice, and that > only appear for customers after deployment and never in a > testing environment.
