On 20 Nov 2013, at 5:03am, Tristan Van Berkom <trista...@openismus.com> wrote:
> More precisely then, in the case that a read transaction is upgraded > to a write transaction, either by issuing an INSERT/DELETE command > or by issuing a nested BEGIN IMMEDIATE command, is it safe to retry > sqlite3_exec() until SQLITE_BUSY is not returned anymore ? It's usually a bad idea to retry in your own code in response to a SQLITE_BUSY. Set SQLite's timeout to whatever value you want (it can be minutes !) and use that to control your retrying for you. SQLite has a good internal algorithm for trying as often as practical without locking up your storage subsystem. If you do get a SQLITE_BUSY back from anything, consider that to be a definitive sign that you have a locking problem and will continue to have one for the near future. Perhaps report to the user that the database is busy and quit. The only useful place where you just might retry in your own code in response to SQLITE_BUSY is where you have a complicated multi-storage multi-process setup where you can get other useful things done while one database file is busy. But for the normal situation, where all your data is in the same database and you can't proceed without access to it, it's probably pointless. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
