Fix "database is locked" errors in multi-threaded programs #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If not specified explicitly, a `begin` will start a deferred transaction, i.e. one that will not attain any locks right away. Instead a read lock is taken when the first select statement is run and this will be upgraded to a write lock on the first insert/update/delete statement. If a concurrent transaction already holds a write lock though, upgrading (or attaining it initially) may fail with SQLITE_BUSY which gets reported as "database is locked". According to https://stackoverflow.com/questions/6369677/database-is-locked-error-in-sqlite3-with-qt this can be worked around by explicilty starting an immediate transaction. This will attain a write lock immediately. It can still fail with SQLITE_BUSY, but before failing it will wait and try again automatically. This has much better chances of succeeding than the retry on upgrading a lock, because there are no previous results that could be invalidated by that concurrent transaction. This fixes the test fail on the upcoming Rakudo 2021.12 release.
18 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If not specified explicitly, a
beginwill start a deferred transaction, i.e.one that will not attain any locks right away. Instead a read lock is taken
when the first select statement is run and this will be upgraded to a write
lock on the first insert/update/delete statement. If a concurrent transaction
already holds a write lock though, upgrading (or attaining it initially) may
fail with SQLITE_BUSY which gets reported as "database is locked".
According to
https://stackoverflow.com/questions/6369677/database-is-locked-error-in-sqlite3-with-qt
this can be worked around by explicilty starting an immediate transaction.
This will attain a write lock immediately. It can still fail with SQLITE_BUSY,
but before failing it will wait and try again automatically. This has much
better chances of succeeding than the retry on upgrading a lock, because there are no
previous results that could be invalidated by that concurrent transaction.
This fixes the test fail on the upcoming Rakudo 2021.12 release.