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

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on HHH-5927:
--------------------------------------

Is there a unit test able to stress this functionality directly? We need to run a competition across implementations ;) Or at least verify how any new implementation would behave.

Strong I like the stile of your patch, I think it's going in the good direction but I'm still of the idea that LIRS would be far superior as eviction strategy and since we could implement [relatively] easily that would avoid the new dependency.

Also I'm not a big fan of the soft references strategy, they might make it easier to implement but in practice you'll see memory usage grow and grow until the whole cache is trashed, and potentially the cache of other frameworks doing similar weird things as well.

LIRS would need a single configuration parameter: an amount of entries it should attempt to keep (but it's not an exact amount, just an estimate).
http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-02-6.pdf

> 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