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 <ljaco...@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 <st...@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 <sa...@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 <st...@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@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 > > > _______________________________________________ > 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
