Ned Batchelder wrote:
I understand your logic about retrying on a SQLITE_BUSY return. This is a
little difficult because of abstraction layers. I have a generic sqlite
Exec method that is used for many different statements. If the database is
busy during a commit, my busy handler will be called. If the database is
busy during an update, my busy handler will not be called. If the
sqlite3_exec function returns BUSY, I should retry immediately, but only if
my busy handler wasn't called. The bookkeeping gets messy.
I would appreciate being able to control this behavior. Perhaps a pragma or
database setting? At the very least, a compile-time switch? I know this
increase the complexity of testing, but one of the reasons I made the switch
from SQLite 2 to SQLite 3 was to get the increased concurrency, and I really
like being able to control the deadlock behavior.
I have your request. In the meantime, the original code that
does busy callbacks for RESERVED locks is still in pager.c,
just commented out using "#if 0". You can find it at line
2420 in the latest version of pager.c. You can easily change it
back in your local copy.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
