[hibernate-dev] Cache region names are not prefixed in 5.3

Radim Vansa rvansa at redhat.com
Fri May 18 03:37:44 EDT 2018


One thing I've stumbled upon: it seems that RegionFactory should call 
its method qualify(String regionName) to produce the prefixed region 
name. Following Hibernate's implementation I use RegionNameQualifier for 
this, which uses prefix + '.' + regionName.

In previous versions the dot was missing from the qualifier - is this 
something that could break backwards compatibility? E.g. in WF to let 
2LC use specific cache configuration you need to set 
`hibernate.cache.infinispan.deployment#entity.name.cfg` - I wonder if 
the qualified region name becomes deployment#.entity.name now...

Radim

On 05/18/2018 09:02 AM, Radim Vansa wrote:
> On 05/18/2018 02:54 AM, Gail Badner wrote:
>>
>>
>> On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner at redhat.com 
>> <mailto:gbadner at redhat.com>> wrote:
>>
>>     I see that HHH-11356 removed prefixes from region names used by
>>     Hibernate.
>>
>>     I also noticed that entity regions are unprefixed and the package
>>     name is removed.
>>
>>
>> Actually, the package names are being included in the region names. 
>> The test I was looking at did not have a package.
>>
>>
>>     I've created 2 issues:
>>     HHH-12599 to add Javadoc to make it clear that region names are
>>     unprefixed;
>>     HHH-12598 to add the package onto entity region names.
>>
>>
>> I've rejected HHH-12598.
>>
>>
>>     Should I create an ISPN issue for hibernate-infinispan (or
>>     whatever it's referred to now) to add the prefixes?
>>
>
> I take it as confirmed that RegionFactory is supposed to do this. 
> Created https://issues.jboss.org/browse/ISPN-9174
>
> R.
>
>>
>>     On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero
>>     <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>
>>         On 17 May 2018 at 12:09, Radim Vansa <rvansa at redhat.com
>>         <mailto:rvansa at redhat.com>> wrote:
>>         > I basically agree with Sanne here that having the prefix
>>         isolated opens
>>         > space for performance improvements, though if certain call
>>         is prefixed,
>>         > RegionFactory can always drop that prefix. The important
>>         thing is to mention
>>         > if the region name is prefixed or not in javadocs. I would
>>         also prefer if
>>         > *all* region names that RegionFactory is supposed to access
>>         followed the
>>         > same strategy (prefixed/not-prefixed).
>>         >
>>         > 5.1 included method
>>         >
>>         >     QueryResultsRegion buildQueryResultsRegion(String
>>         regionName, Properties
>>         > properties)
>>         >
>>         > where StandardQueryCache did the prefix for us, the change
>>         in 5.3 to
>>         >
>>         >     QueryResultsRegion buildQueryResultsRegion(String
>>         regionName,
>>         > SessionFactoryImplementor sessionFactory)
>>         >
>>         > does not indicate that the prefix won't be there and the
>>         javadoc is missing
>>         > completely.
>>         >
>>         > Also, DomainDataRegionConfig.getRegionName() has no javadoc 
>> and
>>         > RegionFactory does not add the prefix.
>>         >
>>         > @Steve could you please amend the javadoc and confirm if RF
>>         should prefix
>>         > region names?
>>         >
>>         > @Sanne while cache manager per deployment is an obvious way
>>         to distinguish
>>         > regions at deployments, CM holds some heavy resources (e.g.
>>         threads) - so I
>>         > while we are supposed to scale number of caches up to
>>         thousands (and we've
>>         > fixed some problems that arise when you have for example ~3k
>>         caches), ATM
>>         > you're not supposed to scale CMs. And I don't think that
>>         we'll focus in this
>>         > direction since the bright future lies in microservices :)
>>
>>         Right, good points. It's a possible optimization I'd like to see
>>         eventually but it's not trivial to get there yet.
>>
>>         Yet assuming a microservices scenario, this does become 
>> trivial to
>>         benefit from: the container knows there's a single deployment, a
>>         single CM. So no need to isolate them at all, just need to
>>         possibly
>>         isolate multiple PUs defined in the same service.
>>
>>         So it will be easy to run hundreds of isolated microservices
>>         on the
>>         same physical CPU and kill each other via process contention :P
>>
>>         >
>>         > Radim
>>         >
>>         >
>>         > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>         >>
>>         >> On 17 May 2018 at 11:11, Sanne Grinovero
>>         <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
>>         >>>
>>         >>> I think this is the RegionFactory's responsibility, as
>>         Hibernate ORM
>>         >>> alone can't know if this is necessary.
>>         >>>
>>         >>> Prefixing is one of many options to isolate caches; a
>>         Cache technology
>>         >>> might wish to use a different approach by implementing a
>>         custom
>>         >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>>         >>
>>         >> Hum, I regret how I wrote the above paragraph.
>>         >>
>>         >> I actually meant that a Cache technology could implement
>>         isolation in
>>         >> many different ways.
>>         >> Using a custom `CacheKeysFactory` is just an example, there
>>         are many
>>         >> other options as well. In fact, I believe a good choice for
>>         >> application servers would be to have an independent
>>         CacheManager for
>>         >> each deployment. Then it can safely inspect the deployment,
>>         see if
>>         >> there are multiple Persistence Units using the same caching
>>         >> technology, and implement further isolation only if 
>> necessary.
>>         >>
>>         >> These thoughts are a consequence of a chat I had with Paul
>>         Ferraro
>>         >> from the WildFly team, as he mentioned the size of the keys
>>         becoming
>>         >> problematic with all the additional prefixing they need to
>>         apply. I
>>         >> hope this will make it possible to e.g. create an "as 
>> small as
>>         >> possible" unique identifier for the deployments to replace 
>> the
>>         >> deployment name during serialization (to identify the
>>         CacheManager)
>>         >> followed by a numeric id indexing the PUs within the
>>         deployment - or
>>         >> nothing altogether in case of single PUs.
>>         >>
>>         >> Of course, I don't expect that to be needed right away; the
>>         >> RegionFactory could just do good old prefixing for now but
>>         I hope
>>         >> we'll explore such improvements in the near future.
>>         >>
>>         >> Thanks,
>>         >> Sanne
>>         >>
>>         >>> Not least the server / deployer might be able to hint the
>>         Cache
>>         >>> provider to tell if isolation is at all necessary.
>>         >>>
>>         >>> In conclusion, by having Hibernate ORM not messing with
>>         prefixes
>>         >>> allows other technologies to implement more efficient
>>         solutions. Our
>>         >>> own code also ends up being more efficient by not needing
>>         to add a
>>         >>> prefix during each and every access to the cache.
>>         >>>
>>         >>> Thanks,
>>         >>> Sanne
>>         >>>
>>         >>> On 17 May 2018 at 06:34, Gail Badner <gbadner at redhat.com
>>         <mailto:gbadner at redhat.com>> wrote:
>>         >>>>
>>         >>>> I see that cache region names are not being prefixed in 
>> 5.3.
>>         >>>>
>>         >>>> EnabledCaching sets the TimestampsRegion region name
>>         >>>> to TimestampsRegion.class.getName(), and sets the
>>         QueryResultsRegion
>>         >>>> region
>>         >>>> name to QueryResultsRegion.class.getName(). [1]
>>         >>>>
>>         >>>> Without a prefix, WildFly is failing intermittently when
>>         there are 2
>>         >>>> persistence units with the query cache enabled due to:
>>         >>>>
>>         >>>> org.infinispan.commons.CacheConfigurationException:
>>         ISPN000453: Attempt
>>         >>>> to
>>         >>>> define configuration for cache
>>         org.hibernate.cache.spi.TimestampsRegion
>>         >>>> which already exists
>>         >>>>
>>         >>>> Entity region names are not being prefixed either.
>>         >>>>
>>         >>>> Should they be prefixed by Hibernate or by the 
>> RegionFactory?
>>         >>>>
>>         >>>> Regards,
>>         >>>> Gail
>>         >>>>
>>         >>>> [1]
>>         >>>>
>>         >>>>
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>> <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92>
>>         >>>> _______________________________________________
>>         >>>> hibernate-dev mailing list
>>         >>>> hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>         >
>>         >
>>         >
>>         > --
>>         > Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>         > JBoss Performance Team
>>         >
>>
>>
>>
>

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team



More information about the hibernate-dev mailing list