[hibernate-dev] InfinispanTestingSetup

[Sanne Grinovero]

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 <rvansa at 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 <rvansa at 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 <rvansa at redhat.com>
>>> JBoss Performance Team
>>>
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>