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
