Sounds like a good plan, it always worked well for me to have prototypes working first and then come the the Infinispan mailing list with a concrete proposal.
+10 for the better conditional API.. I've always struggled with that, you can find some references to the discussion by searching for "MVCC" on the mailing list - even though it's not the appropriate term ;-) On 17 August 2015 at 12:49, Radim Vansa <rva...@redhat.com> wrote: > 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 <rva...@redhat.com> 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 <rva...@redhat.com> >>> JBoss Performance Team >>> > > > -- > 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
