Hi, Thanks for your response. I don't have any idea how multiple connection objects work. Can you please tell us something about that.
Thanks, Roushan On Fri, 2005-07-15 at 20:15, Dennis Jenkins wrote: > Roushan Ali wrote: > > >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. > > > > > > > We have a multi-threaded windows application with four threads. Three > threads need access to the database (all three are producers and > consumers), but one thread is the GUI thread and wants to access the > database while handling WM_TIMER messages (re-entrency issues). So we > allocate 4 database connections during initialization. Each section of > our code uses its own connection. We have a special "stress test" mode > that we can enable. The program remains stable after hours of operation > under the stress test. The program will slow down because of the > database locking mechanism (especially during large transactions), but > it has never crashed due to multiple threads accessing the database used > _different_ connection objects. > > If you are going to be multi-threaded, then why not just use multiple > connection objects (structs - ours are wrapped in a C++ class)? > >