2011/9/29 Simon Slavin <slav...@bigfraud.org> > > On 29 Sep 2011, at 10:38am, Dan Kennedy wrote: > > > On 09/29/2011 03:17 PM, Jaco Breitenbach wrote: > >> In the WAL documentation (http://www.sqlite.org/wal.html) it is hinted > that > >> the checkpoint operation, which is normally in the same thread if > execution > >> as the database commit, could be moved to a separate thread or process. > If > >> I were to run the checkpoint in a separate thread (using > >> sqlite3_wal_checkpoint(DB, NULL)), can I reuse the original database > >> connection, or will the checkpointing interfere with the ongoing > processing > >> (inserts done in the main thread) if the connection is shared? Would it > be > >> better to create a new connection to the database just for the sake of > the > >> checkpointing? > > > > Probably a new connection. All operations on a single sqlite3* > > handle are serialized. > > Howver, the process of checkpointing requires constant access to the > database file, which means it'll be locked. So if you're moving it to > another thread but your main thread is doing to soon do something else with > SQLite, there's probably no point. >
I understood this is not the case; If you have one thread checkpointing, you can have another thread making writes because those go to the WAL file only anyhow and thus there's no locking, so there's no locking (i.e. second thread can do whatever much selects/inserts/deletes/etc. it wants to) unless the second thread would checkpoint also. Please correct me if I'm wrong. > > Simon. > _______________________________________________ > 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
