From: Scott M Stark <scott.stark@jb...> - 2005-11-29 01:07:38
So now that I have the jra data and can browse it, I was reading the
stacktrace image sent to me completely wrong. The contention is simply
on the TransactionImpl monitor from accessing the synchronized lock
method. The toString was a completely seperate call stack, so I should
close the jira issue as invalid and revert the logging to debug level.
The synchronized monitor was still only mapping to a thin lock so
contention was minor for the lock() method. Overally thin locks are
showing up as a hotspot, but the lock() method is a minor portion of
> -----Original Message-----
> From: Adrian Brock=20
> Sent: Monday, November 28, 2005 4:44 PM
> To: Scott M Stark
> Cc: jboss-development@...
> Subject: RE: Transaction=20
> LockContention?Re:boss-transaction/src/main/org/jboss/tm ...
> On Mon, 2005-11-28 at 19:27, Scott M Stark wrote:
> > I need to get the real jra data to be able to view this=20
> correctly. So=20
> > your assertion is that this logging statement really shouldn't be a=20
> > locking problem and should be at least debug level?
> You mean besides the fact that it has already detected=20
> contention (on the transaction) and is trying to log it? :-)
> It is fine at TRACE level. However, it does represent a=20
> potential problem if you are not contending intentionally.=20
> Which is why I left it at DEBUG.
> i.e. a first pass of turning on DEBUG will show the problem=20
> without having to enable the more verbose TRACE.
> Adrian Brock
> Chief Scientist
> JBoss Inc.