12:54 p.m.
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
4:55 p.m.
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
10:40 a.m.
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
10:50 a.m.
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(a)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(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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:39 a.m.
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(a)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(a)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(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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:39 a.m.
I think they believe the reverse.
Personally I am leery of accepting this because ultimately it is yet
another piece of code we are not the experts on but will be responsible for
maintaining.
On Wed, Nov 23, 2016 at 1:39 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
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(a)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(a)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(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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2955
days inactive
2957
days old
5 comments
4 participants
participants (4)
-
Gunnar Morling -
Louis Jacomet -
Sanne Grinovero -
Steve Ebersole