-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Work around issues with sqlite3 database being locked during updates #108
Conversation
# If processing got here with no exceptions then save the event update | ||
# information to database | ||
update.save() | ||
# If processing got here with no exceptions then save the event update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that this final update.save()
should be in the atomic commit block, because it too can fail due to DB locked. That's not good because you have the events being updated without the last date of update being correspondingly updated. (Though I think in normal circumstance it gets cleaned up the next time around with no problems).
Ugh. I thought I could reliably lock the database with my guide stats processing; I'll try that again today and see if I can lock a copy. This PR seems a fine way to at least try again if for some reason the database was locked by reasonable small query or netapp weirdness. |
Maybe try the instructions here: |
I think I looked at that when we started using sqlite but ran into issues with pragma support by sqlite version. Will look again. |
On a locked local copy of events.db via
it looks like I'm getting "django.db.utils.OperationalError: database is locked" without seeing any of the
I'd expect from this PR. |
Grrrr. Will investigate. |
Not clear to me if the exclusive lock via pragma really replicates what we've hit upon by accident in processing though (if the exclusive lock is also a read lock and maybe the lock we're getting is only a write lock?). |
From what you said it is raising what appears to be the same |
From the traceback, it looks like it is throwing the error at Line 119 in 3de2e19
when trying to do that |
From looking through our kadi OperationalError cron task emails, it doesn't look to me like that has happened for us in practice (the errors we see are on save or delete), so I think the exclusive pragma lock might just be a bad test for this. |
Ah, so now I understand your comment about read vs write. Agreed that the exclusive lock is no good, though you might wrap that particular |
3de2e19
to
d91e2a4
Compare
This is a workaround for problems like:
This PR has been tested by running the
ska_testr/packages/kadi/test_regression_long.sh
test, once via ska_testr in Ska flight and once by hand in the repo for this PR. Outputs were diffed and no diffs were seen.I have been unable to reproduce the databased locked problem. I tried locally starting the process to update the database over a 30 day period, then in a separate window repeatedly query the events database. No problem, no joy. So most of this code is not tested and just needs to be looked at carefully.
Plan B was to make a local copy of the events database, update that, and then copy back. But even then it would be better to not have the whole update process stop cold. My feeling is to try this and see if it works. We'll still see warnings pop up if the database was locked.