-
Notifications
You must be signed in to change notification settings - Fork 219
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
feat: make wallet db calls synchronous rather than async #3982
feat: make wallet db calls synchronous rather than async #3982
Conversation
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.
Happy once the unnecessary db.clone
calls are removed
base_layer/wallet/src/output_manager_service/storage/database/mod.rs
Outdated
Show resolved
Hide resolved
Removed spawn blocking calls for db operations from the wallet in the output manager service. (This is the first PR in a couple of PRs required to implement this fully throughout the wallet code.)
01aeb59
to
5475a3a
Compare
#4564) Description --- Removed spawn blocking calls for db operations from the wallet in the key manager service. (This is another PR in a couple of PRs required to implement this fully throughout the wallet code.) Motivation and Context --- As per #3982 and #4555 How Has This Been Tested? --- Unit tests Cucumber tests
…4575) Description --- - Removed spawn blocking calls for db operations from the wallet in the contacts service. (This is another PR in a couple of PRs required to implement this fully throughout the wallet code.) - Reset the wallet's default db connection pool size back to 16 (from 5). Motivation and Context --- As per #3982 and #4555 How Has This Been Tested? --- Unit tests Cucumber tests System-level test
…ari-project#4575) Description --- - Removed spawn blocking calls for db operations from the wallet in the contacts service. (This is another PR in a couple of PRs required to implement this fully throughout the wallet code.) - Reset the wallet's default db connection pool size back to 16 (from 5). Motivation and Context --- As per tari-project#3982 and tari-project#4555 How Has This Been Tested? --- Unit tests Cucumber tests System-level test
Description --- Removed spawn blocking calls for db operations from the wallet in the wallet storage. (This is another PR in a couple of PRs required to implement this fully throughout the wallet code.) Motivation and Context --- As per #3982 and #4555 How Has This Been Tested? --- Unit tests Cucumber tests
A note after the fact. I was curious to see how removing spawn blocking calls (with the assumption that they would become non-blocking) would help with locks, so I looked at this PR a little more closely. Turns out that it's not what this PR does. Rather it's changing the DB requests from async to synchronous calls. So it's even more blocking than before :) (but likely would help with locks). I'm just updating the PR title to reflect this, to help identify the root purpose of the PR |
Personally, I would be more confused by the new title. I would have been happy with |
…ing (transaction service) (#4597) Description --- Removed spawn blocking calls for db operations from the wallet in the transaction service. (This is the last PR in a couple of PRs required to implement this fully throughout the wallet code.) Motivation and Context --- As per #3982 and #4555 How Has This Been Tested? --- Unit tests Cucumber tests
Description
Removed spawn blocking calls for db operations from the wallet in the output manager service. (This is the first PR in a couple of PRs required to implement this fully throughout the wallet code.)
We are using SQLite in WAL mode, which provides concurrent read access and single thread write access for the number of pooled connections configured. Implementing spawn blocking calls on top of that for every db operation is counter productive and easily results in interlock situations within the wallet code, as is the case currently with sending transactions in batch mode.
Although batch mode transactions still does not work with only this PR, it showed a definite improvement monitoring the action with tokio console; all interlocks are now within the transaction service and not in the output manager service anymore.
Motivation and Context
When sending multiple transactions in batch mode (with for example the
make-it-rain
command), the wallet locks up and no transactions are being sent.How Has This Been Tested?
System level tests sending multiple transactions in batch mode to three receiving wallets.
Monitoring with tokio console.