[hibernate-dev] Spring Cache integration

[Gunnar Morling]

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
>