We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Currently there's still a concurrency anomaly even with SI. And that's called write skew.
SSI is an innovation on top of SI that completely removes concurrency anomaly.
I'm not sure how difficult it is to implement, cockroachdb did it on top of rocksdb, but I cannot find the source.
Doing this, should eliminate any need to have DBTransaction.getForUpdate, it would be sufficient to just use get.
DBTransaction.getForUpdate
get
This trades off a little higher conflict contention, because there can be some false positives when throwing a transaction conflict.
At the end of the day, PCC locking should be used anyway to prevent contention in these scenarios.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Specification
Currently there's still a concurrency anomaly even with SI. And that's called write skew.
SSI is an innovation on top of SI that completely removes concurrency anomaly.
I'm not sure how difficult it is to implement, cockroachdb did it on top of rocksdb, but I cannot find the source.
Doing this, should eliminate any need to have
DBTransaction.getForUpdate
, it would be sufficient to just useget
.This trades off a little higher conflict contention, because there can be some false positives when throwing a transaction conflict.
At the end of the day, PCC locking should be used anyway to prevent contention in these scenarios.
Additional context
Tasks
The text was updated successfully, but these errors were encountered: