[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618805#action_12618805
]
Fuad Efendi commented on SOLR-667:
----------------------------------
Paul,
I have never ever suggested to use 'volatile' 'to avoid synchronization' for
concurrent programming. I only noticed some extremely stupid code where SOLR
uses _double_synchronization and AtomicLong inside:
{code}
public synchronized Object put(Object key, Object value) {
if (state == State.LIVE) {
stats.inserts.incrementAndGet();
}
synchronized (map) {
// increment local inserts regardless of state???
// it does make it more consistent with the current size...
inserts++;
return map.put(key,value);
}
}
{code}
Each tool has an area of applicability, and even ConcurrentHashMap just
slightly intersects with SOLR needs; SOLR does not need 'consistent view at a
point in time' on cached objects.
'volatile' is part of Java Specs, and implemented differently by different
vendors. I use volatile (instead of more expensive AtomicLong) only and only to
prevent JVM HotSpot Optimizer from some _not-applicable_ staff...
> 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
> Attachments: ConcurrentLRUCache.java
>
>
> 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.
