-
Notifications
You must be signed in to change notification settings - Fork 69
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## Describe your changes and provide context This change serves to improve the way we track the values of the keys we iterate over when running iterators. Previously, the iterateset would only track the keys that were iterated, and the behavior of the iterator was thought to not include keys that didn't have values present, OR that the readset would be appropriately updated when reading the value from the iterateset. (I'm not yet 100% sure that updating readset WITHIN the tracked iterator is fully necessary, since it may be the case that the readset modifications may have been sufficient to mitigate this issue, but the change is currently in the PR since this is the version of code running on the loadtest cluster for stability testing. However, in cases when an earlier transaction was writing to the range that would be iterated, it was possible that the stale value was read by the transaction handler, BUT the value that got into the readset was the newer one. I believe this has to do with the readset updating based on directly querying values from underlying stores, and overwriting the prior readset value that indicated that the transaction used a stale value. The fix I have made is that during tx execution, the cache memiterator now reads directly form MVKV instead of individually reading from underlying stores. The key difference here is that IF the key is already in the readset, it will serve that STALE value instead of reading into the underlying store where the value may have since mutated. As a result, the behavior we now expect is that one a key is read, ONLY that value that was read will be utilized for the duration of the transaction. This way, we won't potentially mutate the readset by overwriting the key entry with the later value only to have it incorrectly pass validation. Additionally, to more rigorously enforce this behavior, updating the readset now will only update the map IFF the key doesnt already exist in the readset. This should provide better guarantees around catching any stale reads that occur over the lifespan of the transacation execution. ## Testing performed to validate your change Running a lot of iterator heavy workloads on a loadtest cluster to verify that no nondeterminism remains in the iterator workflow
- Loading branch information
Showing
5 changed files
with
71 additions
and
61 deletions.
There are no files selected for viewing
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
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
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
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
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