[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