Ignore me, panicked too quickly... the dot is added there in 5.1 as well. On 05/18/2018 09:37 AM, Radim Vansa wrote: > 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