[infinispan-dev] IRC chat: HB + I9

Wed May 24 11:18:52 EDT 2017

I would suggest option 4# : move the 2LC implementation to Infinispan.

I already suggested this in the past, but to remind the main arguments I have:

 - neither repository is ideal, but having it here vs there is not
just moving the problem as the two projects are different, have
different timelines and different backwards compatibility policies.

 - Infinispan already depends on several Hibernate projects - even
directly to Hibernate ORM itself via the JPA cachestore and indirectly
via Hibernate Search and WildFly - so moving the Infinispan dependency
out of the Hibernate repository helps to linearize the build for one
consistent stack.
For example right now WildFly master contains a combination of
Hibernate ORM and Infinispan 2LC, which is not the same combination as
tested by running the 2LC testsuite; this happens all the time and
brings its own set of issues & delays.

 - Infinispan changes way more often - and as Radim already suggested
in his previous email - there's more benefit in having such advanced
code more closely tied to Infinispan so that it can benefit from new
capabilities even though these might not be ready to be blessed as
long term API. The 2LC SPI in Hibernate on the other hand is stable,
and has to stay stable anyway, for other reasons not least integration
with other providers, so there's no symmetric benefit in having this
code in Hibernate.

 - Infinispan releases breaking changes with a more aggressive pace.
It's more useful for Infinispan 9 to be able to support older versions
of Hibernate ORM, than the drawback of a new ORM release not having
yet an Infinispan release compatible. This last point is the only
drawback I can see, and franckly it's both a temporary situation as
Infinispan can catch up quickly and a very inlikely situation as
Hibernate ORM is unlikely to change these SPIs in e.g. the next major
release 6.0.

 - Infinispan occasionally breaks expectations of the 2LC code, as
Galder just had to figure out with a painful upgrade. We can all agree
that these changes are necessary, but I strongly believe it's useful
to *know* about such breackages ASAP from the testsuite, not half a
year later when a major dependency upgrade propagates to other
projects.

 - The Hibernate ORM would appreciate getting rid of debugging
clustering and networking issues when there's the occasional failure,
which are stressful as they are out of their area of expertise.

I hope that makes sense?

Thanks,
Sanne

On 24 May 2017 at 08:49, Radim Vansa <rvansa at redhat.com> wrote:
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev