this keeps repeating in my setup .
My usescase is as follows.
I have around 220 threads trying to update 220 different keys on the cache. When this happens i get a lot of this locking issues.
In an attemp to solve this i tried to increase teh concurrency level by increasing teh number of locks to 500, still i dont see any benefit.
<locking isolationLevel="REPEATABLE_READ" concurrencyLevel="5000" />
When i see teh jmx console when 220 threads update this , i see only 4 or 5 locks are being used.
When i set the useLockStriping="false" , then it seems to work fine. i see that the number of locks being used go upto 100.
What keys are you using? If you're using custom keys it could be that there are much fewer distinct hashcode values than there are keys. Lock striping assigns locks to keys based on the key's hashcode, so you could actually be using only a small subset of the 500 keys.
If you see the problem with unique strings as keys, this sounds like a problem with lock striping. Please raise a JIRA and attach a test case if you can.
I have lockstriping enabled and would like to maintain it for scalability purposes.
lockstriping won't bring you scalability, but it lowers the memory consumptions. If memory is not an issue for you I suggest disabling it.