-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
weird inexplicable SQLite lockup issues - lockup on connection.Open();
#62
Labels
Milestone
Comments
Related: #50 |
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Sep 3, 2019
As stated in the issue: Seems to be an SQLite issue: https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed gives off the same smell... Adding a `lock(x) {...}` critical section **per library instance** didn't make a difference. Adding a global/singleton `lock(x) {...}` critical section **shared among /all/ library instances** *seems* to reduce the problem, but large PDF import tests show that the problem isn't *gone* with such a fix/tweak/hack.
|
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 2, 2019
As stated in the issue: Seems to be an SQLite issue: https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed gives off the same smell... Adding a `lock(x) {...}` critical section **per library instance** didn't make a difference. Adding a global/singleton `lock(x) {...}` critical section **shared among /all/ library instances** *seems* to reduce the problem, but large PDF import tests show that the problem isn't *gone* with such a fix/tweak/hack.
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 3, 2019
As stated in the issue: Seems to be an SQLite issue: https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed gives off the same smell... Adding a `lock(x) {...}` critical section **per library instance** didn't make a difference. Adding a global/singleton `lock(x) {...}` critical section **shared among /all/ library instances** *seems* to reduce the problem, but large PDF import tests show that the problem isn't *gone* with such a fix/tweak/hack.
GerHobbelt
added a commit
that referenced
this issue
Nov 5, 2019
As stated in the issue: Seems to be an SQLite issue: https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed gives off the same smell... Adding a `lock(x) {...}` critical section **per library instance** didn't make a difference. Adding a global/singleton `lock(x) {...}` critical section **shared among /all/ library instances** *seems* to reduce the problem, but large PDF import tests show that the problem isn't *gone* with such a fix/tweak/hack.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Seems to be an SQLite issue: https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed gives off the same smell...
Adding a
lock(x) {...}
critical section per library instance didn't make a difference.Adding a global/singleton
lock(x) {...}
critical section shared among /all/ library instances seems to reduce the problem, but large PDF import tests show that the problem isn't gone with such a fix/tweak/hack.The text was updated successfully, but these errors were encountered: