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 independently).

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

Reply via email to