Guenther Demetz ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMmQzZTM1NjI1... ) / Improvement ( https://hibernate.atlassian.net/browse/HHH-16827?atlOrigin=eyJpIjoiMmQzZT... ) HHH-16827 ( https://hibernate.atlassian.net/browse/HHH-16827?atlOrigin=eyJpIjoiMmQzZT... ) Avoid useless lockings in NaturalId second level cache. ( https://hibernate.atlassian.net/browse/HHH-16827?atlOrigin=eyJpIjoiMmQzZT... ) Issue Type: Improvement Affects Versions: 5.6.15, 6.2.5 Assignee: Unassigned Created: 20/Jun/2023 06:58 AM Environment: Hibernate 6.2, Java17, Windows10, SQLServer Priority: Minor Reporter: Guenther Demetz ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) When populating second-level-cache by concurrent threads and several threads read the same entities annotated with it comes to a locking-nightmare. This scenario is described in ticket https://hibernate.atlassian.net/browse/HHH-16726. One of the reasons for the bad performance, is that when verifying if the shared cache already contains the key for the natural-id resolution, the current code calls if ( CacheHelper.fromSharedCache( s, cacheKey, cacheAccess ) != null ) { in order to prevent identical re-cachings (NaturalIdResolutionsImpl.java line 251) This is suboptimal and an overshoot for multiple reasons: * fromSharedCache call does not only verify if the shared cache contains the cacheKey, it also tests if the item is readable by comparing session timestamps. If the item is found but considered ‘unreadable', then identical re-caching isn’t prevented. Even more bad: the re-caching attempted is done in vain: NaturaId items aren’t versioned so existing entries get never overriden. public boolean isWriteable(long txTimestamp, Object newVersion, Comparator versionComparator) { ... return version != null && versionComparator.compare( version, newVersion ) < 0; 2. fromSharedCache call does return the item if found and 'readable', but we just need the information if the key is cached or not 3. fromSharedCache call does produce unnecessary read-locks in NaturalId-region and as conseguence of the useless re-caching attempts (point 1) also useless write-locks are done with putFromLoad All this contributes to a huge amount of useless locks in NaturalId cache when it’s get populated. It can avoided by simply calling cacheAccess.contains(cacheKey), see linked PR. ( https://hibernate.atlassian.net/browse/HHH-16827#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16827#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100227- sha1:8ffa416 )