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

[ https://hibernate.onjira.com/browse/HHH-5927?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-5927: ------------------------------------- Couple of things... * @Andres, the branches from Strong and Sanne are based on 4.x, but you could still pull their changes into a 3.6 fork. At least to verify that the changes have desired effect. For example, I think the only real pertinent change on Sanne's in regard to this issue is https://github.com/Sanne/hibernate-orm/commit/4edca8e52bd4df34aadda98202d... and that one should be pretty easy to backport to 3.6 using cherry-pick or diff/patching * Regarding the {{synchonized}} on the {{get}} method, yes we could have gone with a more granular re-entrant read/write lock. That code was added before the switch to Java 5 and at that time we decided against pulling in the oswego library or others just to provide that capability for that one usage. Now that the code bases on Java 6 we could certainly look to change that using a java.util.concurrent.locks.ReentrantReadWriteLock. But I am curious whether {{synchonized}} is the real bottleneck. Hard to say just from the attached profile. * Another option is to get out of writing and maintaining these classes altogether. Its not a core competency of Hibernate as an O/RM solution. Overall this is my preferred solution. There are a couple of options here. *# Using the Google guava library has been suggested. The trouble there is that while they do have "LRU" capability, it is strictly size based; and it is essentially impossible for us to name an appropriate size for all deployments and probably just as impossible expecting users to set that up correctly. See the "semi-roll-our-own" point... *# We could swap in something that is capable of completely replicating the functionality of {{org.hibernate.internal.util.collections.SoftLimitMRUCache}}. Like I mentioned above, guava currently does not fit this bill. Ideally we want that thing to be concurrent (reentrant rather than synchronized) and GC-based. One library that seems to fit all those reqs is http://code.google.com/p/simplelrucache/ I have no experience/affiliation with it. *# We could do a semi-roll-our-own approach where we keep {{org.hibernate.internal.util.collections.SoftLimitMRUCache}} but replace its innards with stuff from guava, http://code.google.com/p/concurrentlinkedhashmap/, etc -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira