When you use SQLITE_CONFIG_MULTITHREAD you can't use the same handle in different threads without some sort of synchronization. With SQLITE_CONFIG_SERIALIZED you can do that because SQLite will do synchronization for you. So there's no difference in concurrency here. If you use different handles in each thread they will communicate with each other via file locking no matter what configuration option you use. So there's no difference in concurrency here either.
Overall for multi-threaded application occasionally needing to do something with database I would suggest a pool of connection handles. When any thread needs to do something with database it gets connection handle from pool, performs what it needs and returns back to pool for other threads to use. If it's too complicated or if you don't want a pool-based design for some other reasons then use one connection handle per thread and don't worry about SQLITE_CONFIG_MULTITHREAD or SQLITE_CONFIG_SERIALIZED options - leave them in default state. Pavel On Mon, Feb 13, 2012 at 5:53 PM, Rittick Gupta <ritt...@yahoo.com> wrote: > What is the difference between the SQLITE_CONFIG_MULTITHREAD & > SQLITE_CONFIG_SERIALIZED options - When a) the same handle is shared between > multiple threads in a process and when different handles are used by threads > in a proceses. > > Is there any difference in concurrency ? What should be used in a multi > threaded process with more than one thread updating and reading the database. > _______________________________________________ > 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
