>> "Externally, from the point of view of another process or thread, two
>> or more database connections using a shared-cache appear as a single
>> connection. The locking protocol used to arbitrate between multiple
>> shared-caches or regular database users is described elsewhere."
>Of course and I understand what your saying, and I'm not asking to
>document every single feature interaction. However, the documentation never
>mentions the possibility of data visibility changes caused by the shared-cache
>mode and, in my opinion, it's a big enough issue that should merit being
>referenced in the documentation.
>> Then there's documentation on WAL mode, explaining how it is possible
>> for a writer to co-exist with readers, via page versioning.
>Now that you mentioned the WAL, shouldn't this actually help prevent this
>scenario? I've never looked at SQLite implementation, but if a
>transaction starts after a successful commit (T1), the new data it tries
>to access shouldn't be cached because it was just now written to the WAL,
>correct?
Yes. Except of course that the new transaction is started against a view of
the database "frozen" by WAL to a time before the data is committed. By the
operation of the first paragraph above, the view of the database is the
"instant" of the first transaction started against the database. Only when all
transactions against the shared cache are committed can another transaction
against the shared cache get the "current" database view ... in other words, as
long as one of the connections using the "shared cache" is in a transaction,
the view of the database stays where it was when the first of a series of
overlapping transactions commenced.
BEGIN A
BEGIN B
COMMIT B BEGIN W
BEGIN C COMMIT W
BEGIN D
COMMIT C
COMMIT D
COMMIT A
BEGIN E
...
The write in transaction W will not be visible until the start of transaction E
because the database view is being held at the view which existed at the time
transaction A was commenced by the shared cache. In other words, from the
perspective of the shared cache, the commit of W only becomes visible after the
commit of A and the before the beginning of E. Even if you committed A
immediately after the update W was complete, the change would still not be
visible until transaction E was commenced.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
