Re: [hibernate-dev] [ORM] EhCache 3 and JCache

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