Thanks for all the input, all of your comments put me on exactly the right track. I was too focused on the behavior of the writes and I didn’t consider the behavior of the reads. I reviewed the logs again and it turns out there was a longer running query that surrounded the entire PUT / GET sequence, and since the same connection was being used for both queries (long, and GET) the GET was being held back on the outer result set. To add to the confusion, another one of these long queries had just started before the previous one finished and so it appeared that it ran and finished quickly after the GET when in reality it was another starting and the previous one finishing.
Jim Borden Software Engineer [email protected] On 2016/09/29 18:09, "sqlite-users on behalf of Clemens Ladisch" <[email protected] on behalf of [email protected]> wrote: Hick Gunter wrote: > Reading "stale" data (i.e. the DB state at the beginning of a transaction) > is at least almost always caused by indvertently leaving a transaction > open. Setting the journal mode to WAL hides this problem, because the > writer is no longer blocked by the reader's transaction. Disable WAL mode > and you will probably find that the writer will find that the "database is > locked". Alternatively, put explicit BEGIN/COMMITs around all reads; then you'll see if you accidentally try to nest transactions. Regards, Clemens _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
