[infinispan-dev] IRC chat: HB + I9

Paul Ferraro paul.ferraro at redhat.com
Wed May 24 11:56:43 EDT 2017


Option #4 would be my preference as well.  The integration into WF has
become increasingly cumbersome as the pace of Infinispan releases (and
associated API changes) has increased.  I would really rather avoid
having to create and maintain forks of hibernate-infinispan to support
the combination of Hibernate and Infinispan that don't exist in the
upstream codebase.

On Wed, May 24, 2017 at 11:18 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
> 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



More information about the infinispan-dev mailing list