We (Wikimedia) are observing SQLITE_BUSY errors in our integration testing. The integration test consists of having a single browser instance view a MediaWiki site which uses SQLite 3.8 for its backend. The browser sends several parallel requests for CSS, JS, etc., and MediaWiki writes to the SQLite database while servicing each of these requests. Thus there is some lock contention.
In strace we see SQLite sleeping when it fails to acquire a SHARED lock, but when it tries to acquire a RESERVED lock, no sleep is done, and an error is immediately reported to the application. https://phabricator.wikimedia.org/T89180 The relevant code has a comment indicating that this is expected behaviour: /* Obtain a RESERVED lock on the database file. If the exFlag parameter ** is true, then immediately upgrade this to an EXCLUSIVE lock. The ** busy-handler callback can be used when upgrading to the EXCLUSIVE ** lock, but not when obtaining the RESERVED lock. */ rc = pagerLockDb(pPager, RESERVED_LOCK); if( rc==SQLITE_OK && exFlag ){ rc = pager_wait_on_lock(pPager, EXCLUSIVE_LOCK); } Is it possible to open a bug or feature request for making SQLite wait on RESERVED locks? Also, do you have any suggestions for a workaround? -- Tim Starling
