OK, thanks for the info. I am truly trying to rewrite the refactor the testsuite as part of [1] so that we can run the tests against all concurrency strategy modes and cache configurations (I am working on tombstone-based 2LC implementation). Also, I hope I can speed up the testsuite (I see that some tests hang for 15 seconds due to some problem in JGroups). Radim [1] https://hibernate.atlassian.net/browse/HHH-10030 On 08/14/2015 12:14 PM, Sanne Grinovero wrote: > > Context is this IRC question: > > <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you > sometimes added InfinispanTestingSetup as @ClassRule and sometimes as > @Rule in HHH-10001? > [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite > compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne > Grinovero] https://hibernate.atlassian.net/browse/HHH-10001 > > Hi Radim, > > I generally wanted to set it as test rule only as that gives a > stricter cleanup verification, but in some cases the excessive > isolation rules would have it fail: apparently some are relying on > previous tests. > > That's something which should be cleaned up in the tests I guess but I > only wanted to workaround the API change in the Infinispan testsuite > without risking a semantic change of the tests.. I also didn't have a > good understanding of the purpose of those tests. > > If you're interesting in cleaning that up, you should be able to try > changing the @ClassRule instances to @Rule instances and you'll see > the test fail. > > Sanne -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team

Right now I want to do that purely in Hibernate integration part, as I don't see why such user approach should not work - replacing remove(key) calls with put(key, tombstone singleton, expiration args). It's possible that I hit the wall somewhere and have to go down to Infinispan. My general plan is to do stuff in Hibernate now, see what's needed and then we could discuss possible infinispan core enhancements (that would get rid of the custom interceptors I've written) on clustering meeting, when I'll see all the trouble in the big picture. In my opinion, infinispan core is in need of user-managed versioning API (used internally for conditional commands, too) rather than tombstones alone. Functional API which is about to appear in 8.0 soon should give us the opportunity to emulate proper versioning (though, with tombstones for removal, too). Radim On 08/17/2015 01:37 PM, Sanne Grinovero wrote: > > Great, I also thought tombstones would be essential to improve the > 2lc. Are you going to bake that feature within Infinispan or as a > customization within the Hibernate code? > > On 17 August 2015 at 08:26, Radim Vansa <rvansa(a)redhat.com&gt; wrote: >> >> OK, thanks for the info. I am truly trying to rewrite the refactor the >> testsuite as part of [1] so that we can run the tests against all >> concurrency strategy modes and cache configurations (I am working on >> tombstone-based 2LC implementation). Also, I hope I can speed up the >> testsuite (I see that some tests hang for 15 seconds due to some problem >> in >> JGroups). >> >> Radim >> >> [1] https://hibernate.atlassian.net/browse/HHH-10030 >> >> >> On 08/14/2015 12:14 PM, Sanne Grinovero wrote: >>> >>> Context is this IRC question: >>> >>> <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you >>> sometimes added InfinispanTestingSetup as @ClassRule and sometimes as >>> @Rule in HHH-10001? >>> [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite >>> compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne >>> Grinovero] https://hibernate.atlassian.net/browse/HHH-10001 >>> >>> Hi Radim, >>> >>> I generally wanted to set it as test rule only as that gives a >>> stricter cleanup verification, but in some cases the excessive >>> isolation rules would have it fail: apparently some are relying on >>> previous tests. >>> >>> That's something which should be cleaned up in the tests I guess but I >>> only wanted to workaround the API change in the Infinispan testsuite >>> without risking a semantic change of the tests.. I also didn't have a >>> good understanding of the purpose of those tests. >>> >>> If you're interesting in cleaning that up, you should be able to try >>> changing the @ClassRule instances to @Rule instances and you'll see >>> the test fail. >>> >>> Sanne >> >> >> >> -- >> Radim Vansa <rvansa(a)redhat.com&gt; >> JBoss Performance Team >> -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team