> > > - We don't currently prepare SQL statements in advance, would this >> technique benefit from somehow preparing statements *before* that >> thread gets the lock on the database ? Can we have multiple threads >> using the SAME database connection preparing SQL Queries at the same >> time (so long as only one is RUNNING the query at once ?). > >With the latest sqlite, I believe you can even have multiple threads >access the same database connection. In this case, access will still >be serialized. >However, you can also have each thread create it's own database >connection, then access the database concurrently (well, with >limitations - there can always only be one writer thread). In this >case you can actually execute several statements in parallel on >different threads (i.e. different database connections).
In fact much of our access is read-only, so being able to work multiple concurrent connections sounds perfect. Could you confirm that we can open and execute additional read only connections to the database whilst we already have a Transaction open for our write thread ? - We BEGIN the transaction on the write thread, then leave that in place and only COMIT the transactions once per minute to coincide with our flush. Can we open and close extra read connections to the database on other threads whilst the write transaction is still active (but idle) ? Thanks for your insight Cheers Mark _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
