Hannah Massey wrote: > If I use separate connections for the reading threads then is there an > advantage to using "shared cache" for those connections?
The shared cache would be useful to reduce memory usage (which should not be a concern except in embedded systems), but concurrent accesses to the same data structure need locking. This locking is done inside most sqlite3_xxx() function calls (see sqlite3_db_mutex()), and independent from the transaction locking. So for maximum performance, use one connection per thread without shared-cache mode. This allows you to run all reading threads in parallel, even when they are accessing the same database, and to use SQLITE_OPEN_NOMUTEX to avoid the locking overhead. (If the lock is not actually contested, the locking overhead would probably be too small to notice.) Regards, Clemens _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
