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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev