[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5927) Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan
Eric Dalquist (JIRA)
noreply at atlassian.com
Wed Feb 22 12:39:48 EST 2012
[ https://hibernate.onjira.com/browse/HHH-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45638#comment-45638 ]
Eric Dalquist commented on HHH-5927:
------------------------------------
Here is a very fast pass at using Guava's CacheBuilder API to re-write SoftLimitMRUCache. I didn't remove the method-level sync code because I didn't spend enough time reviewing the behavior for thread-saftey but I believe that the sync keyword could be removed and the class will still perform correctly in a non-blocking fashion.
https://gist.github.com/1877140
The one thing I didn't fix in this patch is that some tests fail when a null key is used and the Guava Cache APIs don't support null keys or values. That could easily be handled in SoftLimitMRUCache with either short-circuit handling or a placeholder object.
>From what I've read the Guava Cache uses a per-segment LRU algorithm for eviction so your LRU eviction behavior wouldn't be in strict LRU order but for a cache like this that seems ok.
> Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan
> ---------------------------------------------------------------------------------------------------------
>
> Key: HHH-5927
> URL: https://hibernate.onjira.com/browse/HHH-5927
> Project: Hibernate ORM
> Issue Type: Improvement
> Components: core
> Reporter: Strong Liu
> Assignee: Strong Liu
> Attachments: hotspot.png
>
>
> with Order Demo (real-life simulation attempt test app) I have noticed that there is thread contention on createNamesQuery() which sounds suspicious.
> After investigation it boils down to org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan. It serves as a cache (internal, not replacable) for queries using LRU algorithm (supplied from Apache utils).
> Generally speaking, blocking threads in any sort of caches indicates a problem. From about 2000 calls, 700 got blocked (which is also not nice for context switching).
> I guess, one of the problems is that there is exclusive synchronization in get method:
> public synchronized Object get(Object key) {...}
> which could be replaced by a more granular read-write lock.
> org/hibernate/engine/query/QueryPlanCache.java
> org/hibernate/util/SoftLimitMRUCache.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list