[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12461047 ] Jukka Zitting commented on JCR-688: -----------------------------------
> If we know that name prefix resolution causes this amount of pain, > shouldn't we consider adding QName-based addressing in JSR-283? This issue is just a minor implementation detail. There is a price in performance of doing the String<->QName conversions, but the performance hit is probably only noticeable for heavily cached workloads like the example above. The cost of the string operations is likely insignificant as soon as the repository starts hitting the disk. The reason I'm passionate about this is not the performance, but the creeping complexity introduced by the concurrency control. More generally I think the whole name resolution infrastructure in Jackrabbit is much more complex than it really needs to be. > 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 > > Attachments: JCR-688.LocalCache.patch > > > 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
