On Wed, Oct 5, 2016 at 11:53 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 5 Oct 2016, at 4:30pm, Jens Alfke <j...@mooseyard.com> wrote: > > > I did find that SQLite’s own locking was less effective/fair than using > a mutex, and in situations with a lot of write contention could lead to > starvation and timeouts. It’s possible I was doing things wrong, as the > wrapper library I started with included a SQLite busy-handler that would > wait-and-retry. (But IIRC, if I removed the busy handler altogether, SQLite > would just immediately return a db-busy error if another thread had a lock.) > > SQLite has its own built-in busy-handler which is written to work > extremely efficiently with the things SQLite usually needs to do (though > not necessarily with the way you're using SQLite). It's not obvious > whether the wrapper library you're using simply calls this one or > implements its own, possibly less-efficient, one. > I'll admit I haven't done this low level type of SQLite programming in some versions, but the traditional issue is that very, very few applications handle deadlocking correctly. Even with an intelligent busy-handler, there are situations when multiple processes can get into a deadlock and the only way out is for one or more processes to abort their current transactions. I've seen very few applications that handle that situation correctly, and it is generally something that can't be put in a wrapper or utility library (unless it is abstracting out all transactions and database interactions). -j _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
