Re: [sqlite] read_uncommitted=on; question

> You're probably better off ignoring all this stuff and just getting a > working solution. Only then is it worth running some sort of > profiling system on your application to find out which bits are most > worth optimising. Since the sqlite3 library is pretty fast already > you might find that

Re: [sqlite] read_uncommitted=on; question

On 26 May 2009, at 4:56am, Dennis Volodomanov wrote: > Yes, good point... I might compare performance differences in using a > shared connection (multiple threads each opening its own copy of the > database and sharing the connection) vs using the same database from > those threads, unless such

Re: [sqlite] read_uncommitted=on; question

> > It's multiple threads all using the same sqlite3* handle. I call > > sqlite3_enable_shared_cache(1); before opening the database and have > > "PRAGMA read_uncommitted=1;" right after opening the database. > > None of that has any effect as long as you only have one connection. > For > the

Re: [sqlite] read_uncommitted=on; question

"Dennis Volodomanov" wrote in message news:8501919721c3de4c81bca22846b08721a3f...@lazarus.conceiva.com >> Wrong. Statements on the same connection certainly see changes made >> on that connection, committed or otherwise. >> >> Are you talking about the same

Re: [sqlite] read_uncommitted=on; question

> Because catching and dealing with the duplication is handled within > the library function, using these things appropriately should mean > that you don't have to do any fancy worrying about threads, processes > or simultaneity at all: if anything funny goes on, only one of the > INSERT

Re: [sqlite] read_uncommitted=on; question

On 26 May 2009, at 1:11am, Dennis Volodomanov wrote: > 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

Re: [sqlite] read_uncommitted=on; question

> Wrong. Statements on the same connection certainly see changes made on > that connection, committed or otherwise. > > Are you talking about the same connection, or two different connections > in shared cache mode? You started describing the latter, but now keep > mentioning the former. Which

Re: [sqlite] read_uncommitted=on; question

> How do you know the read on connection B doesn't actually happen right > _before_ the write on connection A? What kind of synchronization do you > employ between these two threads? I'm using a critical section (with a CSingleLock) to synchronize threads. However, just looking back at the code

Re: [sqlite] read_uncommitted=on; question

"Dennis Volodomanov" wrote in message news:8501919721c3de4c81bca22846b08721a3f...@lazarus.conceiva.com > If I turn off read_uncommitted, then data won't be "visible" by other > threads (same database connection) until a commit is done, right? Wrong. Statements on

Re: [sqlite] read_uncommitted=on; question

"Dennis Volodomanov" wrote in message news:8501919721c3de4c81bca22846b08721a3f...@lazarus.conceiva.com > 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 do you know the

Re: [sqlite] read_uncommitted=on; question

> > 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

Re: [sqlite] read_uncommitted=on; question

On 26 May 2009, at 12:36am, Dennis Volodomanov wrote: > 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

Re: [sqlite] read_uncommitted=on; question

> > 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 >

Re: [sqlite] read_uncommitted=on; question

On May 25, 2009, at 2:54 PM, Dennis Volodomanov wrote: > Hello all, > > Is it possible that with the read_uncommitted=1 and the shared cache > mode turned on (multithreaded application), that some data that has > been > inserted into the database, but not yet committed, could not be picked >

[sqlite] read_uncommitted=on; question

Hello all, Is it possible that with the read_uncommitted=1 and the shared cache mode turned on (multithreaded application), that some data that has been inserted into the database, but not yet committed, could not be picked up by another thread as being in the database? I thought (from reading