BEGIN CONCURRENT SQLITE BUSY
(1) By anonymous on 2021-03-05 04:54:25 [link] [source]
I have built sqlite based on begin concurrent branch and when doing concurrent writes if there is any contention it gives straight away SQLITE_BUSY database is locked error without respecting busy_timeout parameter, however there is no error in SQLITE master as it is respectng busy_timeout parameter and then sleeps & retry.
(2) By anonymous on 2021-03-05 15:56:11 in reply to 1 [link] [source]
Are you using the database in WAL or WAL2 mode?
(3) By Dan Kennedy (dan) on 2021-03-05 17:44:20 in reply to 1 [source]
The db is in wal mode, correct? "BEGIN CONCURRENT" is no different from "BEGIN" in rollback mode.
In any case SQLite will only use the busy-timeout if there is some prospect of the COMMIT operation succeeding on the second attempt. This is the case if the SQLITE_BUSY is being reported because the client can't get the write lock, but is not so if the SQLITE_BUSY error means the transaction cannot be committed due to page conflicts.
What is being returned by sqlite3_extended_errcode() in these cases?
(4) By Akhilesh Airen (airen977) on 2021-03-06 07:02:42 in reply to 3 [link] [source]
Yes, its WAL mode. Not sure if I could get sqlite3_extended_errcode() as I am using apsw wrapper in Python. Any idea how to get output for sqlite3_extended_errcode() ? Meanwhile I will try using WAL2 mode
(5.2) By Keith Medcalf (kmedcalf) on 2021-03-06 16:17:31 edited from 5.1 in reply to 4 [link] [source]
See the documentation for APSW:
import apsw import sys db = apsw.Connection('') try: db.cursor().execute('crete table x(x)') except apsw.Error as e: print(e, '(error=%d, extended=%d)' % (e.result, e.extendedresult)) raise