[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5927) Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5927?page=c...
]
Sanne Grinovero commented on HHH-5927:
--------------------------------------
I've taken some of the ideas from Strong and created an updated branch at
https://github.com/Sanne/hibernate-core/tree/HHH-5927-part
it's a set of trivial changes, but I believe it could already reduce contention
significantly as every put is currently very expensive, and it was unnecessarily performed
for each get.
I agree we should have a more sophisticated cache, but since that is quite more complex
(more time), I'd be curious to know if just the changes at HHH-5927-part improve your
test scenario significantly.
I'd say that the proper implementation should be provided by the 2nd level cache
provider, if possible. Infinispan definitely provides a modern LIRS implementation which
could be used for this, and I expect EHCache to provide something similar: no need to
reinvent and maintain another implementation.
Performance risk: Suboptimal synchronization in
org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan
---------------------------------------------------------------------------------------------------------
Key: HHH-5927
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5927
Project: Hibernate Core
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