Quote: Why would that distinction matter to it in the first place?
So its clear in the API what lock you have at what time.
This would make predicting what happens in concurrent scenarios much easier.
An explicit "read transaction" is a single line of a program.
With an implicit "read transaction", you must know the semantics of SQLite
locking, and look to see where your first SELECT returns SQLITE_OK.
With read transaction:
```
c1.startRead((tx)=>{ // Issues a BEGIN READ
// X.
sleep(5 seconds);
// SELECT... still the same snapshot from point X being read.
});
```
*No* explicit read transaction:
```
c1.startRead((tx)=>{ // Just issues a normal BEGIN
// X.
sleep(5 seconds);
// SELECT.... What ever was written in the last 5 seconds will be in
the result set, which is unexpected.
});
```
With a explicit "read transaction" the programmer can assume that whenever
`startRead` returns to the runtime the snapshot is guaranteed (it does not
matter how long it takes to issue the first SELECT).
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.
On Wed, Jul 31, 2019 at 3:24 PM Igor Tandetnik <i...@tandetnik.org> wrote:
> On 7/31/2019 6:36 AM, test user wrote:
> > 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.
>
> In the current world, that client would execute BEGIN, then wait a bit,
> then start reading and discover the data written by another process. How
> does it know that those writes occurred between BEGIN and SELECT, and not
> before BEGIN? Why would that distinction matter to it in the first place?
>
> Do you envision some other channel of communication and synchronization
> between these two processes, outside the SQLite database, that would help
> establish that writes occurred after BEGIN? With SQLite alone, it's
> impossible to tell whether the sequence of events was A-B-C or B-A-C - both
> sequences produce the exact same observable behavior. So guarding against B
> squeezing between A and C seems rather pointless.
> --
> 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
