[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627592#action_12627592
]
Antony Bowesman commented on SOLR-667:
--------------------------------------
I have also been considering a concurrent LRU cache for my own application and
seeing this isse made me think about it again. Wouldn't one option be to use a
ReentrantReadWriteLock to synchronise the map rather than complete
synchronisation on the map for both readers and writers. Although that does
not give a free get() it would at least allow concurrent get and still be able
to use the LinkedHashMap and would not require the extra thread. Not sure if
SOLR is java 1.5, but if not you could still use Doug Lea's concurrent package
for pre 1.5 Java.
> Alternate LRUCache implementation
> ---------------------------------
>
> Key: SOLR-667
> URL: https://issues.apache.org/jira/browse/SOLR-667
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Noble Paul
> Fix For: 1.4
>
> Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
> SOLR-667.patch, SOLR-667.patch, SOLR-667.patch
>
>
> The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which
> has _get()_ also synchronized. This can cause severe bottlenecks for faceted
> search. Any alternate implementation which can be faster/better must be
> considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
