On Tue, 7 Feb 2017 14:42:13 +0800 Rowan Worth <row...@dug.com> wrote:
> Note that golang's sql transaction abstraction doesn't map perfectly > to sqlite. Golang does not allow any further operations on the Tx > following a call to Tx.Commit() or Tx.Rollback(). But in sqlite a > transaction remains open if COMMIT fails because the database is > locked. That suggests a failure of imagination in the Go SQLite driver. Most DBMSs return only fatal errors for COMMIT (or success, of course). There is no such thing as "try again". SQLite does not behave that way by default, but can be made to do so. If a busy handler is installed that never returns zero, the only time SQLite returns SQLITE_BUSY is when it determines the transaction cannot be completed i.e., that there's a deadlock. ISTM the Go driver should supply a default busy handler that reduces COMMIT errors to fatal ones. It might expose to the application knobs to change the retry interval. Of course, if the application can replace the busy handler, it also has the option of removing it, and restoring the default behavior. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
