Open astafan8 opened 6 years ago
I think this has now been seen at a QT fridge in Copenhagen. They do, however, also perform some reading in separate processes. I'll try to look into this a bit.
This may or may not be relevant: http://beets.io/blog/sqlite-nightmare.html
tl;dr
Implement atomic transactions the way it's done in #1002 to avoid database is locked
errors.
Just dropping a note that this happened to me and my issues search brought me here. I'm on 670004b06
.
@nikhartman Could you describe what happened in your case? What processes were running? Perhaps you have a full exception message?
@astafan8 Sorry to say, I did not copy the traceback. I was running something along the lines of...
for i in range(10):
# setup measurement
try:
do1d(.......)
except KeyboardInterrupt:
pass
# cleanup
I caught a KeyboardInterrupt (sent from the Jupyter dropdown menu) and got an exception that there was a database error (again, sorry I should have grabbed that). Subsequent measurements failed due to the database being locked.
This is not easy to reproduce. So, here is what happens: a measurement is running in a Jupyter notebook, data is being saved, then the measurement gets interrupted (say KeyboardInterrupt), and then the .db file gets locked. This means that no other program (including the running python kernel) can access the database, the returned error message states that the database is locked.
Restarting the python kernel solves this problem, meaning it unlocks the database.
I have a feeling that the low-level code that handles interaction with sqlite database does not always unlock the database in case of an exception.