Hi Louis, The Caching section from the 5.0 docs is a good place to start to getting to know the basics of Hibernate 2nd level cache. If you want to get into lots of details, you can check my Hibernate Master Class: https://vladmihalcea.com/tutorials/hibernate/ There you can find a lot of resources on how each cache concurrency strategy works, about collection and query cache. If you have any questions, you can ask me anytime. Vlad On Fri, May 20, 2016 at 10:54 AM, Emmanuel Bernard <emmanuel(a)hibernate.org > wrote: > Hello guys, > > (I meant to send that almost a month ago, apologies Louis). > > I’ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how > to restart the progress around JCache and EhCache 3 integration. > Louis is willing to step up to make these a reality but will need a bit > of help to ramp up knowledge wise. Let me list the key subjects. > > == JCache > > I think Sanne has the info somewhere in his brain, what is the status of > the current code? Any detail on what was missing? It would be nice to drive > this one home. > > == Ehcache 3 > > Ehcache 3 has been out recently and it would be nice to get an > integration. The API is very different. > There are a few options: > > 1. make the JCache support extensible to build upon it and use Ehcache > specific features when necessary or useful. Ehcache 3 is a JCache > implementation. > 2. create an new module dedicated to Ehcache 3 and go for it from scratch > basically > 3. change the Ehcache module and move it from v2 to v3 > > 1. might be the conceptual nicest but it’s unclear how doable that is > 2. vs 3. is about migration path for users and whether we consider it a > “breaking change” in a 5.x series > > == Doc and pointers > > As I said, Louis know Ehcache well but needs some input to step into the > magic world of second level caching in Hibernate ORM. Things like where is > the code, how to test it, is there a doc or an example of a well written > one etc. > > Can someone give him a hand? > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

3. change the Ehcache module and move it from v2 to v3

What we had decided before during a discussion with myself, Alex Snaps, Radim and Sanne was to develop a JCache-based L2 case module and that Ehcache 3 would be supported through that mechanism. We'd continue support for the current Ehcahce 2 based hibernate-ehcache module for a short period of time. On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > Hi, > > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < emmanuel(a)hibernate.org&gt; > wrote: > > > 3. change the Ehcache module and move it from v2 to v3 > > > > Please don't do that. > > I'm pretty sure users will need to test Ehcache 3 before going live and it > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible subject > and I'm pretty sure moving to Ehcache 3 will come with its challenges. We > should at least have 1 or 2 versions allowing both Ehcache 2 and 3. > > Moreover, last time I checked, there was no Jgroups replication yet in > Ehcache 3 (or it's not documented). > > -- > Guillaume > _______________________________________________ > 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

Hi Louis, In my opinion, - Yes, of course :) - The plan is to release 5.2 tomorrow. So either this would have to be done tomorrow or the release date pushed back in order for this to be part of 5.2. We could push 5.2 another week, but would the work for this be done in a week? On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet(a)gmail.com&gt; wrote: > Hello, > > I have a couple questions: > * Should there be an issue created to track this work? > * On which branch should this work based if we target a release with 5.2? > > In parallel, I have been reading the pointers Vlad gave and I intend to > verify the current code actually works in all these cases :-) Any chance > there exist some kind of test suite for L2 caching providers? > > Regards, > Louis > > On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> What we had decided before during a discussion with myself, Alex Snaps, >> Radim and Sanne was to develop a JCache-based L2 case module and that >> Ehcache 3 would be supported through that mechanism. We'd continue >> support >> for the current Ehcahce 2 based hibernate-ehcache module for a short >> period >> of time. >> >> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <guillaume.smet(a)gmail.com >> > >> wrote: >> >> > Hi, >> > >> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < >> emmanuel(a)hibernate.org&gt; >> > wrote: >> > >> > > 3. change the Ehcache module and move it from v2 to v3 >> > > >> > >> > Please don't do that. >> > >> > I'm pretty sure users will need to test Ehcache 3 before going live >> and it >> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible >> subject >> > and I'm pretty sure moving to Ehcache 3 will come with its challenges. >> We >> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3. >> > >> > Moreover, last time I checked, there was no Jgroups replication yet in >> > Ehcache 3 (or it's not documented). >> > >> > -- >> > Guillaume >> > _______________________________________________ >> > 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 >> >

Hey Steve, That's a tough question. For tomorrow I don't see how ... Technically the code is out there. But it lacks documentation which is needed: how to select a specific provider and specify a URI which can be used as config source. That still needs to be added. In one week, more likely. I am willing to commit on having it all in proper shape. Which branch will 5.2 be cut from? Because when I last checked some changes happened in master that impacted api but seem to be identified as 6.0 related. What are the chances someone from the hibernate side can look at it in this timeframe? To make sure nothing dumb slips through. Regards, Louis On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > https://hibernate.atlassian.net/browse/HHH-10770 > > On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Hi Louis, >> >> In my opinion, >> >> - Yes, of course :) >> - The plan is to release 5.2 tomorrow. So either this would have to >> be done tomorrow or the release date pushed back in order for this to be >> part of 5.2. We could push 5.2 another week, but would the work for this >> be done in a week? >> >> >> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet(a)gmail.com&gt; >> wrote: >> >>> Hello, >>> >>> I have a couple questions: >>> * Should there be an issue created to track this work? >>> * On which branch should this work based if we target a release with >>> 5.2? >>> >>> In parallel, I have been reading the pointers Vlad gave and I intend to >>> verify the current code actually works in all these cases :-) Any chance >>> there exist some kind of test suite for L2 caching providers? >>> >>> Regards, >>> Louis >>> >>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> What we had decided before during a discussion with myself, Alex Snaps, >>>> Radim and Sanne was to develop a JCache-based L2 case module and that >>>> Ehcache 3 would be supported through that mechanism. We'd continue >>>> support >>>> for the current Ehcahce 2 based hibernate-ehcache module for a short >>>> period >>>> of time. >>>> >>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet < >>>> guillaume.smet(a)gmail.com&gt; >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < >>>> emmanuel(a)hibernate.org&gt; >>>> > wrote: >>>> > >>>> > > 3. change the Ehcache module and move it from v2 to v3 >>>> > > >>>> > >>>> > Please don't do that. >>>> > >>>> > I'm pretty sure users will need to test Ehcache 3 before going live >>>> and it >>>> > shouldn't be tied to an Hibernate upgrade. Cache is a very sensible >>>> subject >>>> > and I'm pretty sure moving to Ehcache 3 will come with its >>>> challenges. We >>>> > should at least have 1 or 2 versions allowing both Ehcache 2 and 3. >>>> > >>>> > Moreover, last time I checked, there was no Jgroups replication yet >>>> in >>>> > Ehcache 3 (or it's not documented). >>>> > >>>> > -- >>>> > Guillaume >>>> > _______________________________________________ >>>> > 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 >>>> >>>

It would be very nice if different implemenations could share parts of the testsuite, no doubts about that. TCK (or functional tests) is useful to find out cases when the implementation does not adhere to specification (which is 'always return the same thing DB would' in the modes but nonstrict-rw). However, race conditions are different matter. From my experience a stress test that the developer runs for a couple of hours is more likely to hit race conditions, that won't show up in functional testsuite. It's possible that there would be less issues due to EhCache's locking nature of the implementation, though. And if the code is meant to be run in clustered environment, it has to be tested that way, as distributed systems tend to behave in unexpected manners. I've written a stress test [1] that covers the basic operations but don't take it as "passed => it's correct". I've tweaked the parameters (most notably NUM_FAMILIES) and probabilities of operations (e.g. removing the InvalidateCache as this breaks many transactions) to manifest different situations. Also, it's important to test with both H2 1.3 and H2 1.4 as these use different locking semantics, leading to races or deadlocks. It shouldn't be hard to reuse most of it - Infinispan specific code deals only with test setup and then introduces random failures in the operations (as RPC/locking timeouts or other errors happen in a distributed system). Trying to reuse the functional testsuite will be more time-demanding task. Radim [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinisp... On 05/25/2016 01:24 AM, Steve Ebersole wrote: > Master is 5.2. There was a previous discussion on this list detailing the > 5.2 changes. Where possible we did not change APIs (though there were a > few cases where that was needed to avoid clashes with JPA method names). > We did change lots of SPIs though. > > If you are willing to commit to getting this to us early next week, I > commit to reviewing the PR. I'd feel most comfortable if Sanne looked it > over as well. > > Also, I do think it would be worthwhile to investigate a "cache provider > tck". Radio, thoughts? > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet(a)gmail.com&gt; wrote: > >> Hey Steve, >> >> That's a tough question. >> For tomorrow I don't see how ... Technically the code is out there. But it >> lacks documentation which is needed: how to select a specific provider and >> specify a URI which can be used as config source. That still needs to be >> added. >> >> In one week, more likely. I am willing to commit on having it all in >> proper shape. >> >> Which branch will 5.2 be cut from? Because when I last checked some >> changes happened in master that impacted api but seem to be identified as >> 6.0 related. >> >> What are the chances someone from the hibernate side can look at it in >> this timeframe? To make sure nothing dumb slips through. >> >> Regards, >> Louis >> >> >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> >>> https://hibernate.atlassian.net/browse/HHH-10770 >>> >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Hi Louis, >>>> >>>> In my opinion, >>>> >>>> - Yes, of course :) >>>> - The plan is to release 5.2 tomorrow. So either this would have to >>>> be done tomorrow or the release date pushed back in order for this to be >>>> part of 5.2. We could push 5.2 another week, but would the work for this >>>> be done in a week? >>>> >>>> >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I have a couple questions: >>>>> * Should there be an issue created to track this work? >>>>> * On which branch should this work based if we target a release with >>>>> 5.2? >>>>> >>>>> In parallel, I have been reading the pointers Vlad gave and I intend to >>>>> verify the current code actually works in all these cases :-) Any chance >>>>> there exist some kind of test suite for L2 caching providers? >>>>> >>>>> Regards, >>>>> Louis >>>>> >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> What we had decided before during a discussion with myself, Alex Snaps, >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and that >>>>>> Ehcache 3 would be supported through that mechanism. We'd continue >>>>>> support >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short >>>>>> period >>>>>> of time. >>>>>> >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet < >>>>>> guillaume.smet(a)gmail.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < >>>>>> emmanuel(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> 3. change the Ehcache module and move it from v2 to v3 >>>>>>>> >>>>>>> Please don't do that. >>>>>>> >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live >>>>>> and it >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible >>>>>> subject >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its >>>>>> challenges. We >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3. >>>>>>> >>>>>>> Moreover, last time I checked, there was no Jgroups replication yet >>>>>> in >>>>>>> Ehcache 3 (or it's not documented). >>>>>>> >>>>>>> -- >>>>>>> Guillaume >>>>>>> _______________________________________________ >>>>>>> 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 -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi Guys, Is it possible to use EhCache 3.x with Hibernate 5.2 ? Many Thanks, Noel On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet <ljacomet(a)gmail.com&gt; wrote: Hi, I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386 I'll be looking at the test referenced by Radim over the next days to see what can be done. Regards, Louis On Wed, May 25, 2016 at 9:52 AM Radim Vansa <rvansa(a)redhat.com&gt; wrote: > It would be very nice if different implemenations could share parts of > the testsuite, no doubts about that. > > TCK (or functional tests) is useful to find out cases when the > implementation does not adhere to specification (which is 'always return > the same thing DB would' in the modes but nonstrict-rw). However, race > conditions are different matter. From my experience a stress test that > the developer runs for a couple of hours is more likely to hit race > conditions, that won't show up in functional testsuite. It's possible > that there would be less issues due to EhCache's locking nature of the > implementation, though. And if the code is meant to be run in clustered > environment, it has to be tested that way, as distributed systems tend > to behave in unexpected manners. > > I've written a stress test [1] that covers the basic operations but > don't take it as "passed => it's correct". I've tweaked the parameters > (most notably NUM_FAMILIES) and probabilities of operations (e.g. > removing the InvalidateCache as this breaks many transactions) to > manifest different situations. Also, it's important to test with both H2 > 1.3 and H2 1.4 as these use different locking semantics, leading to > races or deadlocks. > > It shouldn't be hard to reuse most of it - Infinispan specific code > deals only with test setup and then introduces random failures in the > operations (as RPC/locking timeouts or other errors happen in a > distributed system). Trying to reuse the functional testsuite will be > more time-demanding task. > > Radim > > [1] > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinisp... > > On 05/25/2016 01:24 AM, Steve Ebersole wrote: > > Master is 5.2. There was a previous discussion on this list detailing > the > > 5.2 changes. Where possible we did not change APIs (though there were a > > few cases where that was needed to avoid clashes with JPA method names). > > We did change lots of SPIs though. > > > > If you are willing to commit to getting this to us early next week, I > > commit to reviewing the PR. I'd feel most comfortable if Sanne looked it > > over as well. > > > > Also, I do think it would be worthwhile to investigate a "cache provider > > tck". Radio, thoughts? > > > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet(a)gmail.com&gt; wrote: > > > >> Hey Steve, > >> > >> That's a tough question. > >> For tomorrow I don't see how ... Technically the code is out there. But > it > >> lacks documentation which is needed: how to select a specific provider > and > >> specify a URI which can be used as config source. That still needs to be > >> added. > >> > >> In one week, more likely. I am willing to commit on having it all in > >> proper shape. > >> > >> Which branch will 5.2 be cut from? Because when I last checked some > >> changes happened in master that impacted api but seem to be identified > as > >> 6.0 related. > >> > >> What are the chances someone from the hibernate side can look at it in > >> this timeframe? To make sure nothing dumb slips through. > >> > >> Regards, > >> Louis > >> > >> > >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> > >>> https://hibernate.atlassian.net/browse/HHH-10770 > >>> > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve(a)hibernate.org&gt; > >>> wrote: > >>> > >>>> Hi Louis, > >>>> > >>>> In my opinion, > >>>> > >>>> - Yes, of course :) > >>>> - The plan is to release 5.2 tomorrow. So either this would have > to > >>>> be done tomorrow or the release date pushed back in order for > this to be > >>>> part of 5.2. We could push 5.2 another week, but would the work > for this > >>>> be done in a week? > >>>> > >>>> > >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet(a)gmail.com&gt; > >>>> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I have a couple questions: > >>>>> * Should there be an issue created to track this work? > >>>>> * On which branch should this work based if we target a release with > >>>>> 5.2? > >>>>> > >>>>> In parallel, I have been reading the pointers Vlad gave and I intend > to > >>>>> verify the current code actually works in all these cases :-) Any > chance > >>>>> there exist some kind of test suite for L2 caching providers? > >>>>> > >>>>> Regards, > >>>>> Louis > >>>>> > >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole < steve(a)hibernate.org&gt; > >>>>> wrote: > >>>>> > >>>>>> What we had decided before during a discussion with myself, Alex > Snaps, > >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and > that > >>>>>> Ehcache 3 would be supported through that mechanism. We'd continue > >>>>>> support > >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short > >>>>>> period > >>>>>> of time. > >>>>>> > >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet < > >>>>>> guillaume.smet(a)gmail.com&gt; > >>>>>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < > >>>>>> emmanuel(a)hibernate.org&gt; > >>>>>>> wrote: > >>>>>>> > >>>>>>>> 3. change the Ehcache module and move it from v2 to v3 > >>>>>>>> > >>>>>>> Please don't do that. > >>>>>>> > >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live > >>>>>> and it > >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible > >>>>>> subject > >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its > >>>>>> challenges. We > >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3. > >>>>>>> > >>>>>>> Moreover, last time I checked, there was no Jgroups replication yet > >>>>>> in > >>>>>>> Ehcache 3 (or it's not documented). > >>>>>>> > >>>>>>> -- > >>>>>>> Guillaume > >>>>>>> _______________________________________________ > >>>>>>> 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 > > > -- > Radim Vansa <rvansa(a)redhat.com&gt; > JBoss Performance Team > > _______________________________________________ > 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