-
15. Re: Lock striping broken for Second Level Cache use case
manik Mar 19, 2009 4:58 AM (in response to brian.stansberry)"jason.greene@jboss.com" wrote:
Ah I see this is to handle the case of a blocked/queued thread acquiring a lock. Hmm this kind of defeats the performance benefit of aqs lock queueing
Yeah I know it completely defeats the purpose of AQS queueing and just uses the lock as a token. The real "lock" here is holding a position in the CHM. Sucky, but well... -
16. Re: Lock striping broken for Second Level Cache use case
manik Mar 19, 2009 5:01 AM (in response to brian.stansberry)Ok, working on another approach here.
Incorporating Brian's idea of reusing the lock in the CHM (you're right, we're not striving for fairness here) plus replacing the recursion with a loop will improve performance. -
17. Re: Lock striping broken for Second Level Cache use case
manik Mar 19, 2009 6:11 AM (in response to brian.stansberry)"bstansberry@jboss.com" wrote:
PerElementLockContainer.locks is using the default CHM c'tor which means 16 segments. That's low since this will be a very write-heavy map.
Good point. Updating this to use the concurrencyLevel value, which defaults to 500. -
18. Re: Lock striping broken for Second Level Cache use case
jason.greene Mar 19, 2009 9:30 AM (in response to brian.stansberry)"manik.surtani@jboss.com" wrote:
"bstansberry@jboss.com" wrote:
PerElementLockContainer.locks is using the default CHM c'tor which means 16 segments. That's low since this will be a very write-heavy map.
Good point. Updating this to use the concurrencyLevel value, which defaults to 500.
You might want to use something a lot less than that. 500 is a small value, and that creates 500 hashmaps + locks. You only need a few per cpu. -
19. Re: Lock striping broken for Second Level Cache use case
manik Mar 19, 2009 9:36 AM (in response to brian.stansberry)I'd hate to introduce another cfg variable that essentially does the same thing. At the end of the day, the default is striped locks + cL of 500. If someone switches off striped locking, they're best off re-tuning the cL as well.
-
20. Re: Lock striping broken for Second Level Cache use case
jason.greene Mar 19, 2009 9:44 AM (in response to brian.stansberry)"manik.surtani@jboss.com" wrote:
I'd hate to introduce another cfg variable that essentially does the same thing. At the end of the day, the default is striped locks + cL of 500. If someone switches off striped locking, they're best off re-tuning the cL as well.
I guess my point was more that the default is fine. You could also do something like segments = (concurrency level % 20) -
21. Re: Lock striping broken for Second Level Cache use case
brian.stansberry Mar 19, 2009 10:37 AM (in response to brian.stansberry)"jason.greene@jboss.com" wrote:
I guess my point was more that the default is fine. You could also do something like segments = (concurrency level % 20)
You mean segments = (concurrency level / 20) right? :-) -
22. Re: Lock striping broken for Second Level Cache use case
jason.greene Mar 19, 2009 4:04 PM (in response to brian.stansberry)
You mean segments = (concurrency level / 20) right? :-)
Yes. My brain was in reverse this morning ;) -
23. Re: Lock striping broken for Second Level Cache use case
dukehoops Mar 26, 2009 11:49 AM (in response to brian.stansberry)How can I tell if our system is running into this deadlock problem? Will I see something in the logs or will cache simply at times become inconsistent with DB? If something *is* logged, which statements should I look for (specific class/line would be great - so I can configure logging appropriately)?
thanks!
-nikita -
24. Re: Lock striping broken for Second Level Cache use case
brian.stansberry Mar 26, 2009 12:34 PM (in response to brian.stansberry)You'll see org.jboss.cache.TimeoutException. Exactly where depends on which lock stripes conflict. An example is the stack trace in your post in the middle of this page:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151524&start=20
That particular stack trace has to do with the timestamps cache used with query caching and can be avoided by not using query caching or putting the timestamps in their own cache.
But a similar thing could happen with two entities or collections that happen to hash to the same lock stripe. Same exception but the stack trace would run through the beforeCompletion() method of org.jboss.cache.interceptors.TxInterceptor.LocalSynchronizationHandler or RemoteSynchronizationHandler. -
25. Re: Lock striping broken for Second Level Cache use case
dukehoops Mar 26, 2009 12:37 PM (in response to brian.stansberry)ok, but it would be an Exception (and not a debug/trace statement). thanks!