> The loop is constantly obtaining and releasing the lock on the database (mgr->beginTransaction() calls "BEGIN EXCLUSIVE TRANSACTION"). The idea is to introduce as much contention as possible to see if the transaction locking logic breaks down under stressful circumstances. Using BEGIN EXCLUSIVE bypasses half of sqlite's locking protocol - a more stressful test would be to use regular BEGIN. You also probably have to adapt your code to do that, as (a) sometimes the UPDATE will get an SQLITE_BUSY error, in which case you'd need to ROLLBACK and retry the transaction to maintain the correct counter value, and (b) sometimes the COMMIT will get an SQLITE_BUSY error, in which case you can either ROLLBACK as above or keep trying the COMMIT (which will succeed once the readers relinquish their locks). However note the "keep trying" strategy is affected by [a horrific bug](https://www.sqlite.org/src/tktview/810dc8038872e212361f31daf83ebf32484f3f9f) in sqlite versions 3.17.0 to... 3.32.2? (can't tell from the ticket exactly what version it is fixed in)