[manik]

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...

[manik]

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.

[manik]

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.

[jason.greene]

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.

[manik]

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.

[jason.greene]

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)

[brian.stansberry]

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? :-)

[jason.greene]

You mean segments = (concurrency level / 20) right? :-)

Yes. My brain was in reverse this morning ;)

[dukehoops]

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

[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.

[dukehoops]

ok, but it would be an Exception (and not a debug/trace statement). thanks!