[hibernate-dev] Spring Cache integration

Wed Nov 23 07:39:29 EST 2016

I think they believe the reverse.

Personally I am leery of accepting this because ultimately it is yet
another piece of code we are not the experts on but will be responsible for
maintaining.

On Wed, Nov 23, 2016 at 1:39 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> This is a very interesting contribution, only I am wondering why it should
> be located within the Hibernate ORM project.
>
> It seems interesting to Spring users only, so wouldn't it be better
> located under the Spring umbrella?
>
> --Gunnar
>
>
> 2016-11-22 17:50 GMT+01:00 Louis Jacomet <ljacomet at gmail.com>:
>
> Hi all,
>
> Can't really say anything about the Hibernate integration, but the reason
> Spring caching does not implement JCache is because the abstraction is
> tailored at Spring integration and allows to wrap JCache into Spring Cache,
> because the later existed before the former. SO it would be weird to now
> have a way to get Spring Cache act as a JCache provider.
> Also there is a spec vs. framework abstraction thing at play here.
> Supporting Spring Cache is a much looser contract than supporting JCache
> for any cache implementor.
>
> I guess in an ideal world (or a new framework) you would no longer create a
> cache abstraction instead relying on JCache.
>
> Regards,
> Louis
>
> On Tue, Nov 22, 2016 at 5:41 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > I think this gets back to the idea we discussed when first integrating
> the
> > JCache solution.. namely the idea of provisioning for these regions.  At
> > the time we concluded that it would be better to simply have the JCache
> > integration not deal with the configuration/building of
> > a javax.cache.CacheManager.  Instead it was decided to simply let it
> > consume a javax.cache.CacheManager it acquires from other means.
> >
> > I personally don't see how this "Spring Cache" integration could not
> simply
> > fit into that paradigm.
> >
> > I personally want to avoid supporting any more specific caching backends,
> > especially when it fits into this hibernate-jcache paradigm.  That was
> the
> > point of supporting JCache.
> >
> > What I do not get here is why Spring's
> > `org.springframework.cache.CacheManager` does not simply implement
> > `javax.cache.CacheManager`.  That is by far the easiest solution.
> >
> >
> >
> > On Mon, Nov 21, 2016 at 4:55 PM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> > > My initial reaction to this was of highly skeptical, as I don't see
> > > how adding layers and layers of adapters helps performance, which is
> > > crucial to the very purpose of Caching being effective.
> > >
> > > But the PR mentions interesting things; if indeed people want to use
> > > cloud service abstractions for "general purpose" caching within their
> > > application, and use the same for Hibernate than it makes sense of
> > > course to reuse the initialized components.
> > >
> > > But I've never heard of this "Spring Cloud AWS's Elasticache" .. is
> > > that really a popular solution? And is it sensible to use in this
> > > case? From its docs it seems to support only memcached and Redis.
> > > Caching on a remote shared service will never be as effective as
> > > having a local cache, so I'd suspect the memcached solution would not
> > > be very useful; this leaves Redis which might be interesting but has
> > > poor support for clustering (multi-node, aka scalable deployments).
> > >
> > > In several ways, I wonder if Infinispan itself wouldn't be a better
> > > abstraction to such alternative caching solutions: it can be
> > > configured to use an hybrid of local caching, distributed
> > > invalidation, and offload to an alternative shared storage engine (a
> > > "CacheStore"); such an "hybrid" solution would be a better choice, as
> > > then people can tune local/remote tradeoffs.
> > > Infinispan has a wide collection of such CacheStore implementations;
> > > not least it *did* have support for JClouds storage: it was
> > > implemented, however that component hasn't been updated for a while.
> > > It could be revived if there's such interest.
> > >
> > > I totally agree with the spirit of the PR though: if a system is
> > > configuring caching systems, it should be easy (and more efficient) to
> > > reuse the same configurations and the same "connections" whatever
> > > these are in a specific caching technology, rather than having
> > > Hibernate to start a new instance of these services.
> > >
> > > On an entirely different aspect, I wonder if it's really possible to
> > > have a system built on Redis / memcached to provide the consistency
> > > requirements we typically expect; both Ehcache and Infinispan had to
> > > solve massive challenges to become the fairly good solutions they are
> > > today. My fear is that even just to document eventual limitations,
> > > we'd need to study them quite a bit, probably challenge them
> > > empirically, which would require adding many more tests.
> > >
> > > Thanks,
> > > Sanne
> > >
> > >
> > >
> > > On 21 November 2016 at 18:54, Steve Ebersole <steve at hibernate.org>
> > wrote:
> > > > Someone just opened a PR to add support for Spring Cache as a
> > > second-level
> > > > cache provider[1].  They implemented this by adding a new Hibernate
> > > module
> > > > `hibernate-spring-cache` that essentially wraps Spring Cache as a
> > JCache
> > > > (apparently Spring Cache does not implement the JCache contracts).
> > > >
> > > > Part of the hope with hibernate-jcache was to get out of the business
> > of
> > > us
> > > > maintaining these individual cache integrations.
> > > >
> > > > Anyone have strong opinions here?
> > > >
> > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>