On Apr 20, 2008, at 12:29 AM, James Gregurich wrote: > > oh good! That isn't the version that ships with Leopard, but I can > live with deploying my own version as part of my app. > > Will l get the writer parallelism I'm after as long as each thread > writes exclusively into its own attached db? > > > in other words....two bulk insert operations going on simultaneously > on the same connection but each insert operation going into a > different attached in-memory db.
Probably not. Each sqlite3* handle has a single mutex that it uses to serialize operations. Dan. > > > On Apr 19, 2008, at 9:20 AM, Dan wrote: > >> >> On Apr 19, 2008, at 6:06 AM, James Gregurich wrote: >> >>> >>> I'll ask this question. The answer is probably "no," but I'll ask it >>> for the sake of completeness. >>> >>> >>> Suppose I created an in-memory db. I use the attach command to >>> associate an additional in-memory db. Suppose I assign the main >>> db to >>> thread 1 and the associated db to thread 2. Can I share the >>> connection >>> across the 2 threads if each thread works exclusively in its own db? >>> >>> I am aware that the connection is generally not threadsafe, but will >>> it work if the two threads don't operate on the same db at the same >>> time? >> >> As of 3.5, sqlite connections are threadsafe by default. With >> earlier versions, this trick will not work. >> >> Dan. >> >> >> _______________________________________________ >> 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
