Introduce lock striping
Suggested by @qoire in #300 as follows:
Perhaps we could introduce
lock stripingeither 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
nrefers 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
Thoughts on revisiting this? Still think this is a good idea.
very low priority atm, but would be useful as the database grows and we have a better idea of API requirements
@kzeine candidate for bounty