Quote from: jondecker76 on July 12, 2011, 10:48:53 AM

Now this shows, that in 0.20 seconds, 110 database queries are executed. Multiply by 5 to get queries per second. 550 queries per second is definitely not "low traffic" database stuff (expecially for a CLI utility!)

The locking problem happens because, as you have stated, select queries can happen concurrently, and in fact, if you look at the test.txt i just posted, most all of the queries in the status script are select queries.
The problem is that sqlite requires exclusivity when doing update/insert statements (such as when you add/edit/delete something from the control screen or the update patch system alters the schema). When trying one of these insert/update statements and there is currently a select statement querying the database, the insert/update can't get exclusivity, and errors out. And as you can see, with 500+ queries per second, if you try an insert/update statement, the chances of a select statement happening from other code is at that very moment is very high (though this has been purely timing based, as the status loop currently doesn't run full-out with a built-in delay)

In the end though, it seems like the newer approach is working like it should be, so all is good!

When does it make sense to just go back to MySQL? Seems like most of your headaches would be solved. Just curious since I know you started there, and then went lightweight, only to find out you had locking issues...