Re: [sqlite] Regarding the effects of the COMMIT keyword

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

Re: [sqlite] Regarding the effects of the COMMIT keyword

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

Re: [sqlite] Regarding the effects of the COMMIT keyword

>I am using multiple threads, but in this instance just 2 inside of one >process. I do not change any PRAGMA settings other than user_version and >journal_mode. The two >connections differ only by the fact that one is read >only and one is read-write. It’s possible that I’ve forgotten a

Re: [sqlite] Regarding the effects of the COMMIT keyword

It’s less complicated than a web service. There is no “server” per se, only a lightweight listener object that can accept and respond to HTTP requests (C# HttpListener class). The short explanation is that the library I develop (Couchbase Lite) has a replication function that allows it to

Re: [sqlite] Regarding the effects of the COMMIT keyword

On 29 Sep 2016, at 8:59am, Jim Borden wrote: > There is a web API If you're using a conventional server as the front end to your web service (e.g. Apache, with your code written in PHP/Python/C/whatever) then the server spawns a new process to handle each incoming

Re: [sqlite] Regarding the effects of the COMMIT keyword

I am using multiple threads, but in this instance just 2 inside of one process. I do not change any PRAGMA settings other than user_version and journal_mode. The two connections differ only by the fact that one is read only and one is read-write. It’s possible that I’ve forgotten a finalize

Re: [sqlite] Regarding the effects of the COMMIT keyword

There is a web API, and the application flow is sending a PUT request, which stores the data and then returns a successful status. After that status is received, a GET request is sent. The way the write connection works is that everything is pumped through a single thread and all other

Re: [sqlite] Regarding the effects of the COMMIT keyword

On 29 Sep 2016, at 8:39am, Jim Borden wrote: > I found the following snippet from https://www.sqlite.org/lockingv3.html > > ➢ The SQL command "COMMIT" does not actually commit the changes to disk. It > just turns autocommit back on. Then, at the conclusion of the

Re: [sqlite] Regarding the effects of the COMMIT keyword

Jim Borden wrote: > I found the following snippet from https://www.sqlite.org/lockingv3.html > > The SQL command "COMMIT" does not actually commit the changes to disk. > It just turns autocommit back on. Then, at the conclusion of the > command, the regular autocommit logic takes over and