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
