[
https://issues.apache.org/jira/browse/CASSANDRA-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020077#comment-14020077
]
sankalp kohli commented on CASSANDRA-7359:
------------------------------------------
The problem here is that there is no way to know whether this sync block is
hitting you for different keys in prod across several hundred servers. Testing
it in test environment is not going to have advantage because it all depends on
your rows used and it is not easy to mimic prod.
So may be we just replace it with some lock and see how it performs.
Also what are the concerns with Benedict patch?
> Optimize locking in PaxosState
> ------------------------------
>
> Key: CASSANDRA-7359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7359
> Project: Cassandra
> Issue Type: Improvement
> Reporter: sankalp kohli
> Assignee: Benedict
> Priority: Minor
> Attachments: 7359.txt
>
>
> In PaxosState, we want to lock on same rows and have created 1024 size array
> with java Objects in them to be used for locking.
> We should replace these Objects with some Lock so that we can know whether
> there is contention trying to acquire a lock for different rows.
> We can achieve that by also storing the hash of the row which acquired the
> lock. This will tell us if this needs to be improved.
> Here is an improvement which I was thinking about.
> Say two rows A and B map to the same 1024 bucket which we have. A get the
> lock and B has to wait. Here B can check if his hash is different and create
> a new object and chain it to the other one.
> This looks close to a hashMap with chaining for same key.
> The hard part will be removing the entries no longer being used.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
