> 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
