[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-5927) Performance risk: Suboptimal synchronization in org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan

[Steve Ebersole (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45637#comment-45637 ] 

Steve Ebersole commented on HHH-5927:
-------------------------------------

{quote}
One might not want caching for entities, but still benefit from adding a proper cache library.
{quote}
I am not disagreeing with that.  In fact I suggested that we should ideally be using a third party library to handle this QueryPlanCache above.  What I am specifically arguing against though is linking this to our second level cache SPI.  

Also, I agree that there should not be "options for different implementations" here.  This is strictly a structure that Hibernate uses internally.  I'd prefer to not copy code from some other codebase into our codebase.  If thats the best option, so be it, but I'd very much prefer to not.

> 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