Quote: What importance does it have for you that it already holds an "end-mark? Quote: Why would it matter that a writer did write and commit between the "reader" BEGIN and its first read?
Im writing a library and would like to have an API where the "read transaction" has a clear beginning in time. BEGIN IMMEDIATE forces a "write transaction", but there is no counterpart for a "read transaction". As an example, the client of this library could: - A. Obtain a "read transaction", *without running any SELECTs*. - B. Complete 20 write transactions in another process. - C. Begin reading from the read transaction (A) at the point before the transactions had occurred. At the moment, a "read transaction" is only started on the first SELECT. If a client tries to start a "read transaction" with BEGIN, and that returns SQLITE_OK, its not clear that this has not actually begun any transaction until the first SELECT query. This would enable an API like: const r = await db.startReadTx(); const w = await db.startWriteTx(); // At this point in the runtime it clear when the transactions have begun, and how they will impact other concurrent read/write transactions. On Tue, Jul 30, 2019 at 11:40 PM Olivier Mascia <o...@integral.be> wrote: > > Le 31 juil. 2019 à 00:22, Keith Medcalf <kmedc...@dessus.com> a écrit : > > > > I can see where a BEGIN IMMEDIATE SHARED would be useful in non-WAL mode > though. I will grant that there may be cases where it might be useful in > WAL mode, even though I cannot think of any. > > Fully agree. > > — > Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit besten > Grüßen, > Olivier Mascia > > _______________________________________________ > 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
