On Aug 18, 2017, at 5:33 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
> sanhua.zh wrote:
>> 1. Conn A: Open, PRAGMA journal_mode=WAL
>> 2.ConnB: Open, PRAGMA journal_mode=WAL
>> 3.ConnA: CREATE TABLE sample (i INTEGER);
>> 4.ConnB: PRAGMA table_info('sample')
>>
>> Firstly, both thread 1 and 2 do initialization for their own conn, which is
>> to read to schema into memory.
>> Then, Conn A creates a table with Conn A.
>> Finally, `PRAGMA table_info(sample)` is called in thread 2 with Conn B and
>> it returns nothing.
>>
>> I do know the reason should be the expired in-memory-schema.
>
> No, SQLite automatically detects schema changes.
…but only automatically re-prepares the expired statements if the statement
was originally prepared using sqlite3_prepare*_v2 or _v3.
> It's likely that the second connection started its transaction before
> the first connection committed its own, so it still sees the old state
> of the database.
Unlike most RDBMS environments, SQLite handles DDL as part of
normal transactions. I don’t think this situation would be a problem,
and would be handled by the normal locking mechanisms.
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Intelligence is like underwear: it is important that you have it, but showing
it to the wrong people has the tendency to make them feel uncomfortable." --
Angela Johnson
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
