> Good point. I think the right fix for this is for me to change SQLite > so that it does not invoke the busy callback when it is trying to > acquire a RESERVED lock. If it fails to get a RESERVED lock, then > it returns SQLITE_BUSY right away. The busy callback will then only > be invoked when trying to get a PENDING lock.
I just tried the modification you suggested and it appears to make things much better, thanks. I'd just like to confirm I'm handling the SQLITE_BUSY correctly with this modification: When I receive a SQLITE_BUSY from sqlite3_step and I am in a transaction, I am doing a rollback (I assume this releases any SHARED locks) before retrying the entire transaction. For an automatically started transaction I am just retrying the sqlite3_step. Thanks, Richard
