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
