Hello again Pavel, OK but I am a bit confused. What I have works as a single instance with one DB connection running under different threads as long as only one is using the DB connection at a time. This is with prepared statements "hanging" (not reset) with different threads using different prepared statements (resetting the ones they use before using them). With what you state this should not work (in this case both reads and writes work).
If I understand you correctly, on a single thread using one prepared statement (say a select) then using another prepared statement (say another select) should not work since the 1st prepared statement was not reset. Also what about the time between the statement is executed (sqlite3_step()) and reading the return code and reading the retrieved data? It is my understanding you can't reset the statement until after you have performed these activities. That would imply if what I interpret your statements correctly, that the database is locked until the reset is issued. I appreacate your help. I am just trying to understand what you are trying to tell me. Thanks, John --- On Thu, 5/12/11, Pavel Ivanov <paiva...@gmail.com> wrote: > From: Pavel Ivanov <paiva...@gmail.com> > Subject: Re: [sqlite] Common Multi-treaded Problem > To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> > Date: Thursday, May 12, 2011, 5:58 PM > > Interesting is the impression I > had with prepared statements was the reset was only > necessary if you wanted to reuse that statement. Since > each each DB connection is in its own instance of a class > (with it own set of prepared statements) I would not think > there would be any dependency on different physical prepared > statements on different threads. I would expect this with > incomplete transactions. > > There's no dependency between different prepared > statements, but there > is dependency between transactions as they use the same > database. And > transaction cannot be finished (implicitly or explicitly) > until all > statements in this transaction are reset or finalized. > > > Pavel > > > On Thu, May 12, 2011 at 4:01 PM, John Deal <bassd...@yahoo.com> > wrote: > > Hello Igor, > > > > That very well maybe it. I am not at home so can't > test for sure but I reset the prepared statements right > before I use them so they are left hanging if another thread > came in. > > > > Interesting is the impression I had with prepared > statements was the reset was only necessary if you wanted to > reuse that statement. Since each each DB connection is in > its own instance of a class (with it own set of prepared > statements) I would not think there would be any dependency > on different physical prepared statements on different > threads. I would expect this with incomplete > transactions. > > > > Anyway, thanks for the insight. > > > > John > > > > --- On Thu, 5/12/11, Igor Tandetnik <itandet...@mvps.org> > wrote: > > > >> From: Igor Tandetnik <itandet...@mvps.org> > >> Subject: Re: [sqlite] Common Multi-treaded > Problem > >> To: sqlite-users@sqlite.org > >> Date: Thursday, May 12, 2011, 12:35 PM > >> On 5/12/2011 12:31 PM, John Deal > >> wrote: > >> > When I allow multiple readers with each > thread using a > >> different DB > >> > connection (open with the same flags) and > each thread > >> having > >> > exclusive use of its DB connection (no > sharing of > >> connections) and if > >> > more than one thread is reading the DB at the > same > >> time, the DB > >> > becomes locked for writing even when all the > reads are > >> finished. > >> > >> My first inclination would be to look for places > where you > >> leak active > >> statement handles, by failing to reset or > finalize > >> statements. The read > >> operation is not really finished until the > statement is > >> reset/finalized. > >> -- > >> Igor Tandetnik > >> > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@sqlite.org > >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
