> > I thought (from reading the docs) that with read_uncommitted=1 and > > sqlite3_enable_shared_cache(1), if I INSERT something, it will be > > picked > > up if I do a SELECT on another thread's connection as being in the > > database, even if a COMMIT has not been issued yet. Am I wrong in my > > understanding? > > That's correct. > > Normally, when using shared-cache mode, if connection A writes to a > table > (within a transaction) then a second connection to the same shared- > cache is > unable to read from that table until connection A either COMMITs or > ROLLBACKs > its open transaction. Trying to do so returns SQLITE_LOCKED. However, > when > in read_uncommitted=1 mode, the second connection reads the modified > contents > of the table, even though that data has not yet been (and indeed may > never be) > committed.
Ok, thank you for confirming that. It seems that connection B *sometimes* doesn't see data just inserted into a table by connection A. I will try updating to 3.6.14.2, but most probably that won't change anything. Another question - is it possible for 2 threads sharing the same connection to do an insert at exactly the same time, thus potentially causing this problem? Maybe thread 1 did a "prepare", but not yet "step" and the same data is being "prepared" by thread 2 - would that cause a problem that I'm seeing then? As a side note - I'm monitoring all error codes returned by prepare/step, so any busy states will cause a small sleep and retry. Thanks again, Dennis _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
