On 2020/01/16 12:47 am, Simon Slavin wrote:
On 15 Jan 2020, at 9:44pm, Justin Gielski <justin.giel...@gmail.com> wrote:
*"database is locked release restore point sqlite"*
If there's nothing in your code that caused that to happen, then I would
suspect a transient hardware glitch. Does your code use SAVEPOINTs ?
The database locking mode is set to NORMAL but the database is always
opened exclusively. Could this been a concurrency issue in which 2
connections hit the database at the exact same time?
SQLite is not meant to allow that, with the existance of the
journal/shared-memory files acting as a mutex. If it actually did happen, and
you're not violating anything in the following document, then either you found
a bug in SQLite, or you had hardware problems.
Yes, or a software glitch. Remember that the SQLite database engine is
actual software library code running alongside your own code in the same
process, which means that if your code causes a memory fault (for
whatever reason), the accompanying SQLite code could easily be on the
receiving end of the memory corruption and also no longer work as
expected. This is one of the fundamental differences of having the
Database Engine as part of your process vs. having a process elsewhere
on a server that functions independently (and can check constraints
This is not a typical thing in production though, more expected during
debugging or development, but it can happen in production, especially
having situations like the OP described with rogue database locks from
"hung" processes, etc.
@Justin: I'd start debugging by your processes/code that were hanging,
finding out why that happens, and how your code paths could end up in
such a state would probably solve a lot of problems (including the
sqlite one). That said, if the you can engineer a situation in which it
happens repeatably, that would be very interesting and the devs (and the
rest of us) would be very interested.
sqlite-users mailing list