On 15 March 2018 at 13:04, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Given the changes to the second-level cache SPI, I wonder if we want to > take that as an opportunity to consider dropping the `hibernate-ehcache` > module? > > There are a few reasons I am considering this... > > 1. We have the JCache integration in place and users can use Ehcache > via that support already. > 2. This is really the same discussion we had wrt Spring Cache[1]. IMO > the answer should be consistent. We moved hibernate-infinispan for many of > these same reasons... > 3. A large part of the argument for keeping hibernate-ehcache was that > it is already in place and therefore did not require much effort to > support/maintain. However, given the new SPI there is actually a pretty > big effort to adapt hibernate-ehcache to those new SPIs. So far I am the > one doing that - which in and of itself is fine since I am the one who > changed the SPIs ;) But it makes me think it is far less of a maintenance > effort just to drop it and support just hibernate-ehcache. I guess you meant "support just JCache" ? +1 since the new SPI is different. I do wonder if the JCache API will be a straitjacket for futher performance improvements, but I guess we could re-insert this module if there's more concrete elements? At least any work due to SPI changes could be deferred. We'll still be testing with Ehcache - over JCache - I hope?

Thanks, Sanne > > WDYT? > > > [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

Inline.... On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 15 March 2018 at 13:04, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> Given the changes to the second-level cache SPI, I wonder if we want to >> take that as an opportunity to consider dropping the `hibernate-ehcache` >> module? >> >> There are a few reasons I am considering this... >> >> 1. We have the JCache integration in place and users can use Ehcache >> via that support already. >> 2. This is really the same discussion we had wrt Spring Cache[1]. IMO >> the answer should be consistent. We moved hibernate-infinispan for > many of >> these same reasons... >> 3. A large part of the argument for keeping hibernate-ehcache was that >> it is already in place and therefore did not require much effort to >> support/maintain. However, given the new SPI there is actually a > pretty >> big effort to adapt hibernate-ehcache to those new SPIs. So far I am > the >> one doing that - which in and of itself is fine since I am the one who >> changed the SPIs ;) But it makes me think it is far less of a > maintenance >> effort just to drop it and support just hibernate-ehcache. > I guess you meant "support just JCache" ? > Oops, yes :) +1 since the new SPI is different. I do wonder if the JCache API will > be a straitjacket for futher performance improvements, but I guess we > could re-insert this module if there's more concrete elements? At > least any work due to SPI changes could be deferred. > For sure part of the new SPI design was to allow the cache providers to make some performance decisions up front. Any caching libraries integrating with Hibernate via hibernate-jcache would definitely lose that opportunity (hibernate-jcache would have to make generalized decisions). However, such providers are welcome to implement and provide their own RegionFactory that makes these kind of decisions. That flexibility is not going away - all that goes away is the specific adaptations of our caching SPI to individual caching libraries. We'll still be testing with Ehcache - over JCache - I hope? Yeah, we'd probably use Ehcache as the provider for hibernate-jcache testing. Ideally we'd set up a "matrix" style testing to be able to plug in different providers - possibly even testing against both ehcache and spring-cache. infinispan-hibernate-cache would not fit this model as it does not integrate via the JCache abstraction, though we definitely want to make sure that integration is tested as well.

_______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Mar 15, 2018, at 9:56 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: Inline.... On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero <sanne(a)hibernate.org <mailto:sanne@hibernate.org>> wrote: > On 15 March 2018 at 13:04, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> Given the changes to the second-level cache SPI, I wonder if we want to >> take that as an opportunity to consider dropping the `hibernate-ehcache` >> module? >> >> There are a few reasons I am considering this... >> >> 1. We have the JCache integration in place and users can use Ehcache >> via that support already. >> 2. This is really the same discussion we had wrt Spring Cache[1]. IMO >> the answer should be consistent. We moved hibernate-infinispan for > many of >> these same reasons... >> 3. A large part of the argument for keeping hibernate-ehcache was that >> it is already in place and therefore did not require much effort to >> support/maintain. However, given the new SPI there is actually a > pretty >> big effort to adapt hibernate-ehcache to those new SPIs. So far I am > the >> one doing that - which in and of itself is fine since I am the one who >> changed the SPIs ;) But it makes me think it is far less of a > maintenance >> effort just to drop it and support just hibernate-ehcache. > > I guess you meant "support just JCache" ? > Oops, yes :) +1 since the new SPI is different. I do wonder if the JCache API will > be a straitjacket for futher performance improvements, but I guess we > could re-insert this module if there's more concrete elements? At > least any work due to SPI changes could be deferred. > For sure part of the new SPI design was to allow the cache providers to make some performance decisions up front. Any caching libraries integrating with Hibernate via hibernate-jcache would definitely lose that opportunity (hibernate-jcache would have to make generalized decisions). However, such providers are welcome to implement and provide their own RegionFactory that makes these kind of decisions. That flexibility is not going away - all that goes away is the specific adaptations of our caching SPI to individual caching libraries. We'll still be testing with Ehcache - over JCache - I hope? > Yeah, we'd probably use Ehcache as the provider for hibernate-jcache testing. Ideally we'd set up a "matrix" style testing to be able to plug in different providers - possibly even testing against both ehcache and spring-cache. infinispan-hibernate-cache would not fit this model as it does not integrate via the JCache abstraction, though we definitely want to make sure that integration is tested as well. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>