On 1 March 2017 at 02:39, Matthew Ceroni <matthewcer...@gmail.com> wrote:
> > So since busy_timeout defaults to 0, all write attempts if a lock can't be > obtained will return SQLITE_BUSY immediately. Where does the PENDING lock > come into play here? I thought the PENDING was meant to be an intermediary > step before EXCLUSIVE. Does the busy_timeout impact the writers attempt to > obtain PENDING? Or does the busy_timeout trigger after X amount of ms > between obtaining PENDING and trying to move to EXCLUSIVE? > The writer will be able to grab the PENDING lock immediately, because it already has the RESERVED lock. The PENDING lock will cause any subsequent read transactions to fail (with SQLITE_BUSY), but doesn't affect active read transactions. Thus escalating to EXCLUSIVE can still fail with SQLITE_BUSY when active readers are present. Usually this happens when committing a transaction (unless the transaction exceeds sqlite's memory cache causing it to start writing the DB mid-transaction). If COMMIT fails with SQLITE_BUSY, the transaction *remains open*. The application can retry the COMMIT at a later stage (when hopefully the readers have finished). So even with a busy_timeout of zero PENDING serves a purpose. And even with a non-zero busy_timeout COMMIT can fail with SQLITE_BUSY (if there is an active read transaction which runs for longer than the specified timeout). It looks like the timer is reset for each call to sqlite3_step. Note that when waiting for a lock via busy_timeout, the thread is essentially uninterruptible (sqlite3_interrupt has no effect). -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
