[hibernate-dev] 5.3 - hibernate-ehcache

[Chris Dennis]

+1. From my point of view this makes sense.

I’ll need to confer with higher-ups about what we would then do regarding our copy of the Ehcache 2.x provider and whether we want to port it across to the new SPI.  That should in principle be a separate discussion, but I’m a little too heads-down in a complex release train process today to follow up on this.  Hopefully more interesting/authoritative feedback will be available early next week.

Chris

> On Mar 15, 2018, at 9:56 AM, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Inline....
> 
> On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero <sanne at hibernate.org <mailto:sanne at hibernate.org>> wrote:
> 
>> On 15 March 2018 at 13:04, Steve Ebersole <steve at hibernate.org> 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 at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>