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)?
