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
