[hibernate-dev] Cache region names are not prefixed in 5.3
Radim Vansa
rvansa at redhat.com
Fri May 18 04:01:29 EDT 2018
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 <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