[hibernate-dev] 5.3 cache issues [Requires Steve]

[Yoann Rodiere]

>
> 2) This is easily handled by the providers, if they wish.  They would
> simply map any undefined regions/caches to a pre-defined one (probably
> after warning the user).  Keep in mind that region != cache.  A provider
> might map multiple region names to a single cache.  That was always the
> case, but every provider mapped region <-> cache as 1-1 - the new API makes
> this much more clear.


Just to clarify: this would require cache implementors to provide their own
region factory, and in that case we all agree they can do whatever they
want, which is nice.

The problem is more with the built-in Ehcache and JCache region factories.
Our built-in region factories call getCache(String), and if it returns
null, they throw an exception. So the cache implementors do not have an
easy way to auto-create a cache using some internal, default configuration:
they would have to do that in the getCache(String) method, and it's
arguably not something you want to do in a method with such a name,
especially considering it's exposed to other clients than just Hibernate
ORM. And I'm not sure the JCache specification even allows that.

Ideally we'd like Ehcache/JCache to expose some getOrCreate(String) method,
and decide for themselves whether to throw an exception or not, but well...
they don't. Which explains the suggestion to handle the "default" logic on
our end.

Yoann Rodière
Hibernate NoORM Team
yoann at hibernate.org



On Tue, 3 Jul 2018 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:

> Then not sure why you ask if you already plan on your answer ;)
>
> On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> 1) That was specifically requested
> >>
> >
> > Sure. And we also have users who are unhappy with the new setup.
> >
> > This was also changed for the legacy Ehcache 2 provider which is a pity
> > IMHO.
> >
> >
> >> 2) This is easily handled by the providers, if they wish.  They would
> >> simply map any undefined regions/caches to a pre-defined one (probably
> >> after warning the user).  Keep in mind that region != cache.  A provider
> >> might map multiple region names to a single cache.  That was always the
> >> case, but every provider mapped region <-> cache as 1-1 - the new API
> makes
> >> this much more clear.
> >>
> >> Personally I think that not allowing on-the-fly creation is a good idea,
> >> though maybe it can be made configurable.
> >>
> >
> > Well, the fact is that it can be a perfectly valid setup if you have
> > defined a default template for your caches. Typically, as explained here:
> >
> https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080
> > or in the Ehcache documentation for JCache.
> >
> > If I have 500 entities, using the default default JCache provider, I have
> > to define the configuration for these 500 caches (+ the ones for the
> > collections). Whereas I could use a template for most of them. Note that
> > this is not a rhetorical position: we did that for all our applications
> > with Yoann at our previous job: sane default cache + fine tuning for
> > specific entities.
> >
> > My personal opinion is that we should have a warning explaining the
> > situation and the frameworks could choose to throw an error if they see
> fit
> > but I don't think the default setup should be to throw an error.
> >
> > Apart from the valid default template case, not being to start your
> > application until all your caches are configured doesn't seem very
> helpful
> > when you are developing your application. You don't start your
> development
> > by fine tuning all your caches: it's something you usually do before
> > pushing your app to production and then adjust with the feedback you have
> > from the field.
> >
> > And if you want to be sure, when you push it to production, you can use
> > the new configuration property Yoann introduced in his PR to make it
> fail.
> >
> > --
> > Guillaume
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>