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

Introduce lock striping #305

Open
AlexandraRoatis opened this issue Mar 28, 2018 · 3 comments
Open

Introduce lock striping #305

AlexandraRoatis opened this issue Mar 28, 2018 · 3 comments
Assignees

Comments

@AlexandraRoatis
Copy link
Contributor

Suggested by @qoire in #300 as follows:

Perhaps we could introduce lock striping either at this level or in a layer below this. The rationale being:

  • Assumption is that some block queries are random, therefore may not be hitting blocks that may have high contention (for example the latest n blocks) where n refers to the sync limit that we can rebranch to. Therefore we do not necessarily have to acquire a write lock to the whole object. Merely a write lock to the last 128 blocks. Processes that want to access older historical blocks are still free to do so.

  • We can tune this to our API requirements, for example, the API has a method that scans the last n blocks within a block range looking for events.

https://stackoverflow.com/questions/16151606/need-simple-explanation-how-lock-striping-works-with-concurrenthashmap

@qoire
Copy link
Contributor

qoire commented Jun 27, 2018

Thoughts on revisiting this? Still think this is a good idea.

@AlexandraRoatis
Copy link
Contributor Author

very low priority atm, but would be useful as the database grows and we have a better idea of API requirements

@qoire
Copy link
Contributor

qoire commented Oct 1, 2018

@kzeine candidate for bounty

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

No branches or pull requests

2 participants