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 <gbad...@redhat.com >> <mailto:gbad...@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 >> <sa...@hibernate.org <mailto:sa...@hibernate.org>> wrote: >> >> On 17 May 2018 at 12:09, Radim Vansa <rva...@redhat.com >> <mailto:rva...@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 >> <sa...@hibernate.org <mailto:sa...@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 <gbad...@redhat.com >> <mailto:gbad...@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@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 <rva...@redhat.com <mailto:rva...@redhat.com>> >> > JBoss Performance Team >> > >> >> >> > -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
