[hibernate-dev] 5.3 - hibernate-ehcache

[Steve Ebersole]

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.