> > Ok, thank you for confirming that. It seems that connection B > > *sometimes* doesn't see data just inserted into a table by > > connection A. > > How long a time is 'just' ? You might want everything to be > completely up-to-date but does that record really matter if it didn't > exist a fraction of a second ago ? If the difference matters to you > then perhaps you shouldn't be using read_uncommitted. That way your > database will be completely consistent (assuming you're using > transactions properly).
Basically these are file names being inserted into a table, so, before each insert we check whether that file exists in the table already or not (by doing a SELECT on an indexed lowercase full file path). So, it really matters to me that the first insert completes and data is available for a select that follows immediately from another thread (but same database connection). If I turn off read_uncommitted, then data won't be "visible" by other threads (same database connection) until a commit is done, right? So, that would be pretty much the same as what's happening now with read_uncommitted turned on. > > 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? > > Nope. Even if you're using a multi-core processor, your motherboard > can still only handle one memory access instruction at a time. > Multiprocessing is an illusion carefully maintained by the operating > system. Yes, I understand that, but would the first "prepare" already lock the database for writing, or does that occur only during a "step"? Thank you, Dennis _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
