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