On 09/29/2011 05:20 PM, Mikael wrote:
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.
That's correct. Checkpointing does not block either readers
or writers.
However, if the other connections are writing fast enough, or
holding long read-transactions open a large percentage of the time,
the WAL file might end up growing indefinitely. This is usually
more of a problem for performance tests than actual applications.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
