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

[Radim Vansa]

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 >> > 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
>>>     mailto:sa...@hibernate.org>> wrote:
>>>
>>>     On 17 May 2018 at 12:09, Radim Vansa >>     > 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
>>>     mailto:sa...@hibernate.org>> wrote:
>>>     >>>
>>>     >>> I think this is the RegionFactory's responsibility, as
>>>    

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

[Radim Vansa]

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 > > 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
>>     mailto:sa...@hibernate.org>> wrote:
>>
>>     On 17 May 2018 at 12:09, Radim Vansa >     > 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
>>     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
>>     cust

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

[Radim Vansa]

On 05/18/2018 02:54 AM, Gail Badner wrote:
>
>
> On Thu, May 17, 2018 at 5:24 PM, Gail Badner  > 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
> mailto:sa...@hibernate.org>> wrote:
>
> On 17 May 2018 at 12:09, Radim Vansa  > 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
> 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.
>   

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

[Gail Badner]

On Thu, May 17, 2018 at 5:24 PM, Gail Badner  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?
>
> On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero 
> wrote:
>
>> On 17 May 2018 at 12:09, Radim Vansa  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  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 technolo

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

[Gail Badner]

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.

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.

Should I create an ISPN issue for hibernate-infinispan (or whatever it's
referred to now) to add the prefixes?

On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero 
wrote:

> On 17 May 2018 at 12:09, Radim Vansa  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  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  wrote:
> 
>  I see that cache region names are not being prefixed in 5.3.
>

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

[Sanne Grinovero]

On 17 May 2018 at 12:09, Radim Vansa  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  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  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

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

[Radim Vansa]

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 :)

Radim

On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> On 17 May 2018 at 11:11, Sanne Grinovero  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  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
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Sanne Grinovero]

On 17 May 2018 at 11:11, Sanne Grinovero  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  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
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Sanne Grinovero]

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`.

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  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
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev