[
https://hibernate.onjira.com/browse/HHH-5927?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-5927:
-------------------------------------
# I had thought about frequency-based eviction. Ideally you'd want a policy based on
both.
# You make a huge assumption that that would "run faster". Caching is always a
trade off between processor and memory. You are maybe only considering the processor
aspect when saying it will run faster. But if the size we choose along with other stuff
going on in that particular JVM cause memory to come close to max the application will
most decidely not "run faster"; it will run far slower.
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