The way I got around it was at the programmer level. Rollback,delay and try again.
Thanks, Garyc --- On Sun, 5/16/10, Sam Carleton <scarle...@miltonstreet.com> wrote: > From: Sam Carleton <scarle...@miltonstreet.com> > Subject: Re: [sqlite] Understanding locking and connections > To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> > Date: Sunday, May 16, 2010, 9:15 AM > On Sat, May 15, 2010 at 6:12 PM, > Simon Slavin <slav...@bigfraud.org> > wrote: > > > > > On 15 May 2010, at 10:09pm, Sam Carleton wrote: > > > > > Everything appears to be running fine, > but... I was reading the thread > > late > > > last week about SQLITE_BUSY and it got me > wondering if I am doing things > > > correctly. > > > > I would like to see documentation on what the Right > Thing to do is for > > errors like SQLITE_BUSY from each of the common > functions, e.g. on _step, on > > _finalise, etc.. It should include details of > whether SQLite does its own > > retries or of how the programmer is expected to time > retries. > > > Simon, > > I did, but I did not see ANYTHING that addressed my > question: > > "I don't seem to have a performance issue with the general > approach of doing > multiple open/closes for each request, are there pitfalls > out there that I > am missing? Might it be worth the time and effort to > keep the same > connection through each request?" > > Where can I go to find those answers? > _______________________________________________ > 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
