On 2/17/15, Tim Starling <tstarling at wikimedia.org> wrote: > 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? >
I'm guessing that running "PRAGMA busy_timeout=4000;" (or some other reasonable number of milliseconds) shortly after opening the database connection will likely cure your problem. https://www.sqlite.org/pragma.html#pragma_busy_timeout You might also want to consider switching to WAL mode (https://www.sqlite.org/wal.html) for its greater concurrency. -- D. Richard Hipp drh at sqlite.org
