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

[sqlite] Regarding the effects of the COMMIT keyword

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 causes the actual commit to