[infinispan-dev] IRC chat: HB + I9

Wed May 24 03:49:38 EDT 2017

Hi Galder,

I think that (3) is simply not possible (from non-technical perspective) 
and I don't think we have the manpower to maintain 2 different modules 
(2). The current version does not seem ready (generic enough) to get 
into Infinispan, so either (1), or a lot of more work towards (4) (which 
would be my preference).

I haven't thought about all the steps for (4), but it seems that 
UnorderedDistributionInterceptor and LockingInterceptor should get into 
Infinispan as a flavour of repl/dist cache mode that applies update in 
parallel on all owners without any ordering; it's up to the user to 
guarantee that changes to an entry are commutative.

The 2LC code itself shouldn't use the 
TombstoneCallInterceptor/VersionedCallInterceptor now that there is the 
functional API, you should move the behavior to functions.

Regarding the invalidation mode, I think that a variant that would void 
any writes to the entry (begin/end invalidation) could be moved to 
Infinispan, too. I am not even sure if current invalidation in 
Infinispan is useful - you can't transparantly cache access to 
repeatable-read isolated DB (where reads block writes), but the blocking 
as we do in 2LC now is probably too strong if we're working with DB 
using just read committed as the isolation level. I was always trying to 
enforce linearizability, TBH I don't know how to write a test that would 
test a more relaxed consistency.

Btw., I've noticed that you've set isolation level to READ_COMMITTED in 
default configuration - isolation level does not apply at all to 
non-transactional caches, so please remove that as it would be just a noise.

Radim

On 05/23/2017 03:07 PM, Galder Zamarreño wrote:
> Hi all,
>
> I've just finished integrating Infinispan with a HB 6.x branch Steve had, all tests pass now [1].
>
> Yeah, we didn't commit on the final location for these changes.
>
> As far as I know, Hibernate master is not 6.x, but rather 5.2.x. There's no 5.2.x branch in Hibernate main repo. 6.x is just a branch that Steve has.
>
> These are the options availble to us:
>
> 1. Integrate 9.x provider as part of 'hibernate-infinispan' in Hibernate 6.x branch.
>
> 2. Integrate 9.x provider as part of a second Infinispan module in Hibernate 5.x branch.
>
> 3. Integrate 9.x provider as part of 'hibernate-infinispan' in Hibernate 5.x branch. This is problematic for since the provider is not backwards compatible.
>
> 4. Integrate 9.x provider in infinispan and deliver it as part of Infinispan rather than Hibernate.
>
> I'm not sure which one I prefer the most TBH... 1. is the ideal solution but doesn't seem there will be a Hibernate 6.x release for a while. 2./3./4. all have their downsides... :\
>
> Thoughts?
>
> [1] https://github.com/galderz/hibernate-orm/commits/t_i9x_v2
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 16 May 2017, at 17:06, Paul Ferraro <paul.ferraro at redhat.com> wrote:
>>
>> Thanks Galder.  I read through the infinispan-dev thread on the
>> subject, but I'm not sure what was concluded regarding the eventual
>> home for this code.
>> Once the testsuite passes, is the plan to commit to hibernate master?
>> If so, I will likely fork							 these changes into a WF module (and adapt it
>> for Hibernate 5.1.x) so that WF12 can move to JGroups4+Infinispan9
>> until Hibernate6 is integrated.
>>
>> Radim - one thing you mentioned on that infinispan-dev thread puzzled
>> me: you said that invalidation mode offers no benefits over
>> replication.  How is that possible?  Can you elaborate?
>>
>> Paul
>>
>> On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño <galder at redhat.com> wrote:
>>> I'm on the move, not sure if Paul/Radim saw my replies:
>>>
>>> <pferraro> galderz, rvansa: Hey guys - is there a plan for Hibernate &
>>>     ISPN 9?
>>> <rvansa> pferraro: Galder has been working on that
>>> <rvansa> pferraro: though I haven't seen any results but a list of
>>>     stuff that needs to be changed
>>> <pferraro> galderz: which Hibernate branch are you targeting?
>>> <rvansa> pferraro: 5.2, but there are minute differences between 5.x
>>>     in terms of the parts that need love to get Infinispan 9 support
>>> *** Mode change: +v vblagoje on #infinispan by ChanServ
>>>     (ChanServ at services.)
>>> <pferraro> rvansa: are you suggesting that 5.0 or 5.1 branches will be
>>>     adapted to additionally support infinispan 9?  how is that
>>>     possible?
>>>> pferraro: i'm working on it as we speak...
>>>> pferraro: down to 16 failuresd
>>>> pferraro: i started a couple of months ago, but had talks/demos to
>>>     prepare
>>>> pferraro: i've got back to working on it this week
>>> ...
>>>> pferraro: rvansa
>>>> rvansa: minute differences my ass ;p
>>>> pferraro: did you see my replies?
>>>> i got disconnected while replying...
>>> <pferraro> hmm - no - I didn't
>>> <pferraro> galderz: ^
>>>> pferraro: so, working on the HB + I9 integration as we speak
>>>> pferraro: i started a couple of months back but had talks/demos to
>>>     prepare and had to put that aside
>>>> pferraro: i'm down to 16 failures
>>>> pferraro: serious refactoring required of the integration to get it
>>>     to compile and the tests to pass
>>>> pferraro: need to switch to async interceptor stack in 2lc
>>>     integration and get all the subtle changes right
>>>> pferraro: it's a painstaking job basically
>>>> pferraro: i'm working on
>>>     https://github.com/galderz/hibernate-orm/tree/t_i9x_v2
>>>> pferraro: i can't remember where i branched off, but it's a branch
>>>     that steve had since master was focused on 5.x
>>>> pferraro: i've no idea when/where we'll integrate this, but one
>>>     thing is for sure: it's nowhere near backwards compatible
>>>> actually, fixed one this morning, so down to 15 failures
>>>> pferraro: any suggestions/wishes?
>>>> is anyone out there? ;)
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team