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 threads must wait their turn while the single thread executes the work one by one (the exception being, as I found out painfully a few months ago, stepping through prepared statements). If a transaction is entered, then any further transactions requested by the transaction are handled immediately as save points. Only when the outermost transaction commits may the next work item be executed. So by the time the successful HTTP response code is returned the data should be saved and committed. That is why it is so puzzling that the next request (which does not use explicit transactions, just executes a few SELECT statements) returns 404. To me it seemed obvious that it was seeing an old state, but the question was why is it seeing an old state?
PRAGMA synchronous is 2 (NORMAL, I believe?) Jim Borden Software Engineer jim.bor...@couchbase.com <http://www.couchbase.com/connect> On 2016/09/29 16:51, "sqlite-users on behalf of Clemens Ladisch" <sqlite-users-boun...@mailinglists.sqlite.org on behalf of clem...@ladisch.de> wrote: 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 causes the actual > commit to disk to occur. > > Does that mean that the actual commit happens after the execution of > “COMMIT” (i.e. it is in a sense asynchronous)? No, "at the conclusion" happens _before_ the execution has finished. > I have two connections to a database file and reports that writing to > one and then immediately querying from another causes the second > connection to show the entry as missing. [...] > The database file is operating in WAL mode In WAL mode, the writer and the reader do not block each other. This implies that the reader sees the old state of the database. What exactly does "immediately" mean? Is there some synchronization mechanism that actually ensures that the second transaction is started _after_ the first one has finished? (And when doing multiple SELECTs, it's easy to have them in a single transaction because the first one isn't finalized early enough.) What is the PRAGMA synchronous setting? Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
