Skip to content
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

[occ] Add validation logic to scheduler #332

Closed
wants to merge 47 commits into from

Conversation

stevenlanders
Copy link
Contributor

@stevenlanders stevenlanders commented Oct 16, 2023

Describe your changes and provide context

  • This adds a versioned store for each incarnation of a transaction
  • Scheduler re-executes based on validation output

Testing performed to validate your change

  • Unit test for scheduler (confirms expected tx output for conflicting transactions)

udpatil and others added 27 commits September 13, 2023 10:04
## Describe your changes and provide context
This adds some comments with some useful code pointers for existing
logic and discussing future OCC work

## Testing performed to validate your change
NA
## Describe your changes and provide context
Add multiversion store data structures file, and implement the
multiversioned item

## Testing performed to validate your change
Added unit tests to verify behavior
## Describe your changes and provide context
This adds the incarnation field to the multiversion item data structure.

## Testing performed to validate your change
updated unit tests
## Describe your changes and provide context
This implements the multiversion with basic functionality, but still
needs additional work to implement the iterator functionality and/or
persisting readsets for validation

## Testing performed to validate your change
Added unit tests for basic multiversion store
## Describe your changes and provide context
- `ConcurrencyWorkers` represents the number of workers to use for
concurrent transactions
- since concurrrency-workers is a baseapp-level setting, implementations
(like sei-chain) shouldn't have to pass it (but can)
- it defaults to 10 if not set (via cli default value)
- it defaults to 10 in app.toml only if that file is being created (and
doesn't exist)
- if explicitly set to zero on command line, it will override with the
default (for safety)
- cli takes precedence over the config file
- no one has to do anything to get it to be 10 (no config changes no
sei-chain changes required (aside from new cosmos version))

## Testing performed to validate your change
- Unit Tests for setting the value
- Manually testing scenarios with sei-chain
## Describe your changes and provide context
This adds in functionality to write the latest multiversion values to
another store (to be used for writing to parent after transaction
execution), and also adds in helpers for writeset management such as
setting, invalidating, and setting estimated writesets.

## Testing performed to validate your change
Unit testing for added functionality
## Describe your changes and provide context
- `sei-cosmos` will receive a list of transactions, so that sei-chain
does not need to hold the logic for OCC
- This will make the logic easier to test, as sei-cosmos will be fairly
self-contained
- Types can be extended within a tx and within request/response

Example interaction:
<img
src="https://github.com/sei-protocol/sei-cosmos/assets/6051744/58c9a263-7bc6-4ede-83ab-5e34794510b1"
width=50% height=50%>

## Testing performed to validate your change
- This is a skeleton for a batch interface
## Describe your changes and provide context
This implements an mvkv store that will manage access from a transaction
execution to the underlying multiversion store and underlying parent
store if the multiversion store doesn't have that key. It will first
serve any reads from its own writeset and readset, but if it does have
to fall through to multiversion store or parent store, it will add those
values to the readset.

## Testing performed to validate your change
Unit tests
…ore (#330)

## Describe your changes and provide context
This adds in validation for transaction state to multiversion store, and
implements readset validation for it as well.

## Testing performed to validate your change
Unit Test
@stevenlanders stevenlanders changed the title Add versioned store to each tx context [occ] Add versioned store to each tx context Oct 16, 2023
@stevenlanders stevenlanders marked this pull request as ready for review October 16, 2023 23:23
stevenlanders and others added 4 commits October 17, 2023 13:34
## Describe your changes and provide context
This implements Iterator and ReverseIterator for mvkv for the KVStore
interface. The memiterator will be composed of versionindexedstore and
multiversionstore, and will yield values in a cascading fashion firstly
from the writeset, and then second from the multiversion store.

This still needs optimization to persisted sorted keys instead of
reconstructing sorted keys each time.

## Testing performed to validate your change
Unit test to verify basic functionality
@stevenlanders stevenlanders changed the title [occ] Add versioned store to each tx context [occ] Add validation logic to scheduler Oct 18, 2023
@stevenlanders
Copy link
Contributor Author

Closing in favor of #336 (to avoid messy PR commit history after merges/rebases)

stevenlanders added a commit that referenced this pull request Oct 19, 2023
## Describe your changes and provide context
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

## Testing performed to validate your change
- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 2, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 8, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 18, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 18, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 25, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Jan 31, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
codchen pushed a commit that referenced this pull request Feb 6, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Feb 27, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
udpatil pushed a commit that referenced this pull request Mar 1, 2024
- This was copied from #332 which became unwieldy due to commit history
(merges/rebases)
- Adds scheduler logic for validation
- In this initial version it completes all executions then performs
validations (which feed retries)
- Once we start benchmarking we can make performance improvements to
this
- Retries tasks that fail validation and have no dependencies

- Scheduler Test verifies multi-worker with conflicts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants