[hibernate-dev] 5.3 - hibernate-ehcache

[Radim Vansa]

On 03/15/2018 02:56 PM, Steve Ebersole wrote:
> Inline....
>
> On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero <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.

Before Infinispan provides native implementation to 5.3/6.0 SPIs, JCache 
is a good way to bridge the gap. So if you're setting up a matrix 
testing, adding Infinispan JCache provider would give us some confidence 
that we can recommend that bridge in the meantime.

R.

> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team