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(a)redhat.com> wrote:
Right now I want to do that purely in Hibernate integration part, as
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
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> wrote:
>> OK, thanks for the info. I am truly trying to rewrite the refactor the
>> testsuite as part of  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
>>  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.
>> Radim Vansa <rvansa(a)redhat.com>
>> JBoss Performance Team
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team