On 18 Jun 2019, at 2:11pm, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote:
> So have I understood correctly, that in an application, this kind of > SQLITE_BUSY handling is sufficient: > > BEGIN > UPDATE #1 > SELECT #2 > UPDATE #3 > COMMIT <----- check for busy here and retry only the commit on failure I believe that the above is correct. Though you should be checking the return code for every SQLite3 call, just because catching an unexpected code there can save you days of debugging time. Actually, you're better off setting a timeout rather than handling retry in your own code: <https://sqlite.org/c3ref/busy_timeout.html> (or use the PRAGMA). People tend to set tiny timeouts and then waste programming time implementing their own retry code. But what you really want is to set a timeout of a minute or more. After all, which is better, to catch a working retry after 45 seconds or to present an error message to the user ? The exception is when your SQLite operation is blocking the main thread of a real-time program. But that's rare. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
