If, and it is possible for there to be sequencing to enforce it, You KNOW that step 1, get a read transaction (which the OP presumes implies includes getting the lock) occurs before step 2, and thus step 4 seeing changes from step 3 says something is wrong.
Yes, if you only can use the database to communicate, this may not be possible, but if the program does the get a read transaction itself, and only after getting the confirmation starts the process that does the write, it can positively know that it ‘started’ the read transaction before the write transaction was started. SQLite (I believe) documents that the BEGIN statement doesn’t set the read lock until the select, so its behavior is as documented, just not as the OP desires. For them, it is desired that the beginning of the transaction also gets the lock, so the their API point of begin a transaction marks the point that the read data is locked to. One option, that they are pursuing (but seems to have been denied) is to have SQLite have a variant of BEGIN that includes getting the read lock. Their other option is to just do a dummy SELECT on the database to force getting the lock. The callers to their API won’t be able to tell the difference, except maybe a bit of execution time. > On Jul 31, 2019, at 4: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
