Hi All, Please clear my one more doubt. Is it true that either using the SQLITE_THREADSAFE=1 as compile time flag or using SQLITE_OPEN_FULLMUTEX with sqlite3_open_v2 are same thing. Both can be used interchangeably. Correct me if I am wrong.
Secondly, Is it possible by any mean that for shared connection amongst thread, the insert on one thread does not become part of the transaction on other thread. And one last thing just to confirm that it is not at all possible to open different in memory db connection from different threads? With Best Regards Gaurav Sharma -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Pavel Ivanov Sent: Thursday, July 30, 2009 5:10 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Use of in memory db > What I assume is if I share an in memory db connection handle across threads > then it will not be sqlite's responsibility but the user's responsibility to > protect multiple insert/update statements. On the other hand if the > connection to physical db is shared amongst threads then sqlite takes care of > synchronization between multiple insert/update from multiple threads. Your assumption is wrong. When you share the same connection among several threads SQLite works with the same scenario no matter if you connection to in-memory database or to physical file. And this scenario depends on compilation options and flags given to sqlite3_open. With default compilation options if you gave flag SQLITE_OPEN_NOMUTEX then it's your responsibility to protect with mutexes, if you gave flag SQLITE_OPEN_FULLMUTEX then SQLite makes this work for you. What you meant to say maybe is that if you have different connections in each thread to the same physical file then SQLite can make more fine-grained synchronization between threads. This scenario is not applicable to in-memory database because there's no way you can open several connections to the same in-memory database. > Basically a broader question is that, Is there any way to avoid sharing of > connection handle and even then be able to work on the same memory db from > multiple threads. As I've already said: no. > Or any one can suggest how best the mutex can be used if I share the > connection and then perform transactions (insert, update). If you have resource shared between threads there's only one way to use it - protect each access to it with mutex. There's no other ways to do it and no tricks can be done in here. The only trick that you can do is to avoid sharing of the resource and develop some memory structure that will allow you concurrent access from different threads with the pattern your application needs. But SQLite is not your fellow here - it doesn't offer this kind of memory structure. Pavel On Thu, Jul 30, 2009 at 7:16 AM, Sharma, Gaurav<gaurav.sha...@safenet-inc.com> wrote: > Hi All, > > Is there any way through which without using the mutex lock mechanism > multiple threads can perform INSERT in bulk on same memory db. What I assume > is if I share an in memory db connection handle across threads then it will > not be sqlite's responsibility but the user's responsibility to protect > multiple insert/update statements. On the other hand if the connection to > physical db is shared amongst threads then sqlite takes care of > synchronization between multiple insert/update from multiple threads. > > Basically a broader question is that, Is there any way to avoid sharing of > connection handle and even then be able to work on the same memory db from > multiple threads. I really wish to avoid the burden of using mutex for every > (insert or update) in multi threaded scenario. That actually supposed to put > lot of overhead on my application. > > Or any one can suggest how best the mutex can be used if I share the > connection and then perform transactions (insert, update). > > With Best Regards > Gaurav Sharma > > > The information contained in this electronic mail transmission > may be privileged and confidential, and therefore, protected > from disclosure. If you have received this communication in > error, please notify us immediately by replying to this > message and deleting it from your computer without copying > or disclosing it. > > > _______________________________________________ > 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 The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
