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 <rva...@redhat.com> 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-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java > > 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 <ljaco...@gmail.com> 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 <st...@hibernate.org> > wrote: > >> > >>> https://hibernate.atlassian.net/browse/HHH-10770 > >>> > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <st...@hibernate.org> > >>> 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 <ljaco...@gmail.com> > >>>> 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 <st...@hibernate.org> > >>>>> 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.s...@gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard < > >>>>>> emman...@hibernate.org> > >>>>>>> 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@lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> hibernate-dev mailing list > >>>>>> hibernate-dev@lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>>> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
