[ https://issues.apache.org/jira/browse/CASSANDRA-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019787#comment-14019787 ]
Aleksey Yeschenko commented on CASSANDRA-7359: ---------------------------------------------- I highly doubt this is an issue in real world. Have you observed this being a problem IRL, [~kohlisankalp], or is it purely hypothetical? If purely hypothetical, then let it be as is. If not, then I agree with 1) - let's expand the range and be done with it. > 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)