Remove contention due to PessimisticUnversionedNode.getLock() ------------------------------------------------------------- Key: JBCACHE-1543 URL: https://jira.jboss.org/jira/browse/JBCACHE-1543 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Locking Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.2.1.CR1 PessimisticUnversionedNode.getLock() shows up as a middling contention hotspot in profiling tests. The method always calls initLock(), which is a synchronized method. So any lock attempts will first have to briefly get the monitor for the node before they can move on to acquiring the lock. This adds contention in the case of for higher level structural nodes in a tree (e.g. Fqn.ROOT). Solution is to make the PessimisticNodeLock.lock field volatile and then only call initLock() if it is null; aka double-checked locking. Making the field volatile ensures that the IdentityLock object is fully constructed before it is visible to other threads reading PessimisticUnversionedNode.lock, which is the requirement for making double-checked locking correct. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira