Have you set a SQLite timeout of a few seconds ? See here:
<http://www.sqlite.org/c3ref/busy_timeout.html>
I was expecting to get SQLITE_BUSY and nothing else.
If the _BUSY state lasts for longer than the timeout you've set,
then you'll get _IOERR. Setting a long timeout gives the software
longer to deal with the busy condition quietly before concluding
that something has locked up the databases longer than reasonable.
This explanation doesn't fit for a number of reasons.
- I've observed this problem using both the native Python sqlite3
library and apsw, and the native library sets a default timeout of 5s,
and there's nothing that takes remotely that long in my example.
- The documentation referenced above says that SQLITE_BUSY will be
returned if the timeout is exceeded, and I do in fact occasionally
receive such return codes (when using apsw, which has no default
timeout). The condition under which SQLITE_IOERR_BLOCKED might be
returned (I'm referring to <http://www.sqlite.org/c3ref/busy_handler.html
> here) would seem applicable only to the process trying to commit,
but as my log showed, it's the process trying to begin a transaction
that is receiving the error code.
- In any case, I'm receiving SQLITE_IOERR_LOCK, not
SQLITE_IOERR_BLOCKED.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
