On 22 Jan 2013, at 5:39pm, Ward Willats <sqlite-us...@wardco.com> wrote:
> I have a bunch of home-grown C++ wrappers for Sqlite and when my app needs to > use the DB, most routines just instance one of these DB wrapper objects on > the stack and go for it. The constructor creates a new DB connection, which > is closed at destructor time. Very convenient. > > All is well, EXCEPT, I have ONE big, long transaction that collects and > stores a lot of data from some sensors. If this data is big enough, it will > eventually cause that connection to obtain an exclusive lock on the DB. Now > if the data collection code subsequently calls any subroutine that instances > up a quick and dirty DB object on the stack and tries to use it, a "database > is locked" (or "database busy" on write) error will be returned. > > My app is single threaded. Just on opinion in what I hope is many. First, you should definitely set whatever timeout you want SQLite to use. Five seconds is not unusual. <http://www.sqlite.org/c3ref/busy_timeout.html> Change the code used in your one big thread so that it counts the number if INSERT/UPDATEs it does and changes transactions and does a little pause after every thousand ops. Or hundred. Whatever. set pausecounter to 1000 BEGIN with each SQL command ... decrement pausecounter if pausecounter < 0 { COMMIT pause for 1 second BEGIN } COMMIT If you do that you shouldn't have to change any of the quick and convenient coding you've used in other routines. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
