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

On 05/18/2018 02:54 AM, Gail Badner wrote: > > > On Thu, May 17, 2018 at 5:24 PM, Gail Badner <gbadner(a)redhat.com > <mailto:gbadner@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(a)hibernate.org <mailto:sanne@hibernate.org>> wrote: > >         On 17 May 2018 at 12:09, Radim Vansa <rvansa(a)redhat.com >         <mailto:rvansa@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@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(a)hibernate.org <mailto:sanne@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(a)redhat.com >         <mailto:gbadner@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... > <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... >         >>>> _______________________________________________ >         >>>> hibernate-dev mailing list >         >>>> hibernate-dev(a)lists.jboss.org >         <mailto:hibernate-dev@lists.jboss.org> >         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev> >         > >         > >         > >         > -- >         > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> >         > JBoss Performance Team >         > > > >