Quote: Connection 2 just happened to write lots of data and commit before connection 1 obtained a read transaction Quote: if SELECT on Connection 1 just happens to beat the write on Connection 2
- The order in the example is exact, not a guess what might happen. - Each step runs in a single thread on an event loop and is awaited, and assumed to return with OK. - The read transaction at the start is definite (supposing BEGIN READ existing). All I am saying is on "Connection 1: Get read transaction" could be: BEGIN READ NOT BEGIN; SELECT * FROM some_table; Quote: Why again do you care how BEGIN behaves Im just suggesting that if you can obtain a write transaction with a single trip over the FFI and an explicit command "BEGIN IMMEDIATE" the same could be true for "read transactions" I care because I think its a better API design which would then allow better higher level libraries. On Wed, Jul 31, 2019 at 9:46 PM Igor Tandetnik <i...@tandetnik.org> wrote: > On 7/31/2019 12:32 PM, test user wrote: > > In some runtimes, the scheduling of functions is unpredictable, so > although > > you will not have a `sleep 5` in the code, the runtime can produce this > > effect on loaded systems or with programs with long running sync > functions. > > > > > > An example of how you might use this: > > - Connection 1: Get a read transaction. > > > > - Connection 2: Get a write transaction, write a lot of data, commit. > > - Connection 2: SELECT report summary B. > > > > - Connection 1: SELECT report summary A, > > > > - Diff A and B to see what changed. > > Suppose you discovered that B and A are in fact the same. How do you know > whether that occurred because a) "get a read transaction" is "broken" in > that it doesn't actually acquire the lock as you expected, or because b) > Connection 2 just happened to write lots of data and commit before > connection 1 obtained a read transaction? > > In other words, in your example A == B is possible even if BEGIN worked > the way you expect it to work, and grabbed a read lock immediately. > Similarly, A != B is possible with BEGIN working the way it does now, if > SELECT on Connection 1 just happens to beat the write on Connection 2. It's > a matter of timing and scheduling, which you yourself posit is > unpredictable. > > So, since both A==B and A!=B are possible with either behavior of BEGIN, > why again do you care how BEGIN behaves? > -- > Igor Tandetnik > > _______________________________________________ > 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
