[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12460221 ] Marcel Reutegger commented on JCR-688: --------------------------------------
I have to apologize, my post in JCR-685 was not precise enough. What acutally happens when multiple threads access the CachingNamespaceResolver is the following: because even a get() call on the LRUMap modifies the internal data structures those calls must be synchronized. This basically serializes access on the LRUMap even though only a small critical section should be synchronized: the method moveToMRU(). Calculating the hash code, doing the lookup in the hashtable and checking whether the keys are equal does not require synchronization and multiple threads can do this concurrently. I agree that this does not necessarily have to go into the 1.2 release, but it certainly is a problem, because the CachingNamespaceResolver in the NamespaceRegistry is a single instance repository wide and used by all threads that access the repository. Since name resolution is involved in nearly every operation I think it should allow maximum concurrent threads. It is correct that the proposed change will not lower the number of synchronized sections but the sections will be significantly smaller. So to be precise this improvement is not really to avoid monitor contention but to allow more concurrent access to the CachingNamespaceResolver. > Improve name resolution > ----------------------- > > Key: JCR-688 > URL: http://issues.apache.org/jira/browse/JCR-688 > Project: Jackrabbit > Issue Type: Improvement > Components: core > Reporter: Jukka Zitting > Priority: Minor > Fix For: 1.3 > > > As discussed in JCR-685, the current CachingNamespaceResolver class contains > excessive synchronization causing monitor contention that reduces performance. > In JCR-685 there's a proposed patch that replaces synchronization with a > read-write lock that would allow concurrent read access to the name cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
