<p dir="ltr">A lot to read through here so I apologize up front if I missed something...</p>
<p dir="ltr">So to be fair I am biased as I would really like to not have to deal with these integrations :) That said, I do really believe that the best option is to move this code out of the hibernate/hibernate-orm repo. To me that could mean a separate repo altogether (infinispan/infinispan-hibernate-l2c, or sim) or into infinispan proper if Infinispan already has Hibernate dependency as Sanne mentioned somewhere. </p>
<p dir="ltr">As far as Hibernate.. master is in fact 5.2, 6.0 exists just in my fork atm - we are still discussing the exact event that should trigger moving that 6.0 branch up stream. 6.0 timeline is still basically unknown especially as far as a Final goes. </p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, May 24, 2017, 11:04 AM Galder Zamarreño <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding Steve,<br>
<br>
Scott Marlow just reminded me that you've advocated for Infinispan 2LC provider to be moved to Infinispan source tree [2].<br>
<br>
So, you might want to add your thoughts to this thread?<br>
<br>
Cheers,<br>
<br>
[2] <a href="http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2015/%23hibernate-dev.2015-08-06.log.html" rel="noreferrer" target="_blank">http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2015/%23hibernate-dev.2015-08-06.log.html</a><br>
--<br>
Galder Zamarreño<br>
Infinispan, Red Hat<br>
<br>
> On 24 May 2017, at 17:56, Paul Ferraro <<a href="mailto:paul.ferraro@redhat.com" target="_blank">paul.ferraro@redhat.com</a>> wrote:<br>
><br>
> Option #4 would be my preference as well. The integration into WF has<br>
> become increasingly cumbersome as the pace of Infinispan releases (and<br>
> associated API changes) has increased. I would really rather avoid<br>
> having to create and maintain forks of hibernate-infinispan to support<br>
> the combination of Hibernate and Infinispan that don't exist in the<br>
> upstream codebase.<br>
><br>
> On Wed, May 24, 2017 at 11:18 AM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>> wrote:<br>
>> I would suggest option 4# : move the 2LC implementation to Infinispan.<br>
>><br>
>> I already suggested this in the past, but to remind the main arguments I have:<br>
>><br>
>> - neither repository is ideal, but having it here vs there is not<br>
>> just moving the problem as the two projects are different, have<br>
>> different timelines and different backwards compatibility policies.<br>
>><br>
>> - Infinispan already depends on several Hibernate projects - even<br>
>> directly to Hibernate ORM itself via the JPA cachestore and indirectly<br>
>> via Hibernate Search and WildFly - so moving the Infinispan dependency<br>
>> out of the Hibernate repository helps to linearize the build for one<br>
>> consistent stack.<br>
>> For example right now WildFly master contains a combination of<br>
>> Hibernate ORM and Infinispan 2LC, which is not the same combination as<br>
>> tested by running the 2LC testsuite; this happens all the time and<br>
>> brings its own set of issues & delays.<br>
>><br>
>> - Infinispan changes way more often - and as Radim already suggested<br>
>> in his previous email - there's more benefit in having such advanced<br>
>> code more closely tied to Infinispan so that it can benefit from new<br>
>> capabilities even though these might not be ready to be blessed as<br>
>> long term API. The 2LC SPI in Hibernate on the other hand is stable,<br>
>> and has to stay stable anyway, for other reasons not least integration<br>
>> with other providers, so there's no symmetric benefit in having this<br>
>> code in Hibernate.<br>
>><br>
>> - Infinispan releases breaking changes with a more aggressive pace.<br>
>> It's more useful for Infinispan 9 to be able to support older versions<br>
>> of Hibernate ORM, than the drawback of a new ORM release not having<br>
>> yet an Infinispan release compatible. This last point is the only<br>
>> drawback I can see, and franckly it's both a temporary situation as<br>
>> Infinispan can catch up quickly and a very inlikely situation as<br>
>> Hibernate ORM is unlikely to change these SPIs in e.g. the next major<br>
>> release 6.0.<br>
>><br>
>> - Infinispan occasionally breaks expectations of the 2LC code, as<br>
>> Galder just had to figure out with a painful upgrade. We can all agree<br>
>> that these changes are necessary, but I strongly believe it's useful<br>
>> to *know* about such breackages ASAP from the testsuite, not half a<br>
>> year later when a major dependency upgrade propagates to other<br>
>> projects.<br>
>><br>
>> - The Hibernate ORM would appreciate getting rid of debugging<br>
>> clustering and networking issues when there's the occasional failure,<br>
>> which are stressful as they are out of their area of expertise.<br>
>><br>
>> I hope that makes sense?<br>
>><br>
>> Thanks,<br>
>> Sanne<br>
>><br>
>><br>
>><br>
>> On 24 May 2017 at 08:49, Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>> wrote:<br>
>>> Hi Galder,<br>
>>><br>
>>> I think that (3) is simply not possible (from non-technical perspective)<br>
>>> and I don't think we have the manpower to maintain 2 different modules<br>
>>> (2). The current version does not seem ready (generic enough) to get<br>
>>> into Infinispan, so either (1), or a lot of more work towards (4) (which<br>
>>> would be my preference).<br>
>>><br>
>>> I haven't thought about all the steps for (4), but it seems that<br>
>>> UnorderedDistributionInterceptor and LockingInterceptor should get into<br>
>>> Infinispan as a flavour of repl/dist cache mode that applies update in<br>
>>> parallel on all owners without any ordering; it's up to the user to<br>
>>> guarantee that changes to an entry are commutative.<br>
>>><br>
>>> The 2LC code itself shouldn't use the<br>
>>> TombstoneCallInterceptor/VersionedCallInterceptor now that there is the<br>
>>> functional API, you should move the behavior to functions.<br>
>>><br>
>>> Regarding the invalidation mode, I think that a variant that would void<br>
>>> any writes to the entry (begin/end invalidation) could be moved to<br>
>>> Infinispan, too. I am not even sure if current invalidation in<br>
>>> Infinispan is useful - you can't transparantly cache access to<br>
>>> repeatable-read isolated DB (where reads block writes), but the blocking<br>
>>> as we do in 2LC now is probably too strong if we're working with DB<br>
>>> using just read committed as the isolation level. I was always trying to<br>
>>> enforce linearizability, TBH I don't know how to write a test that would<br>
>>> test a more relaxed consistency.<br>
>>><br>
>>> Btw., I've noticed that you've set isolation level to READ_COMMITTED in<br>
>>> default configuration - isolation level does not apply at all to<br>
>>> non-transactional caches, so please remove that as it would be just a noise.<br>
>>><br>
>>> Radim<br>
>>><br>
>>> On 05/23/2017 03:07 PM, Galder Zamarreño wrote:<br>
>>>> Hi all,<br>
>>>><br>
>>>> I've just finished integrating Infinispan with a HB 6.x branch Steve had, all tests pass now [1].<br>
>>>><br>
>>>> Yeah, we didn't commit on the final location for these changes.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> These are the options availble to us:<br>
>>>><br>
>>>> 1. Integrate 9.x provider as part of 'hibernate-infinispan' in Hibernate 6.x branch.<br>
>>>><br>
>>>> 2. Integrate 9.x provider as part of a second Infinispan module in Hibernate 5.x branch.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 4. Integrate 9.x provider in infinispan and deliver it as part of Infinispan rather than Hibernate.<br>
>>>><br>
>>>> 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... :\<br>
>>>><br>
>>>> Thoughts?<br>
>>>><br>
>>>> [1] <a href="https://github.com/galderz/hibernate-orm/commits/t_i9x_v2" rel="noreferrer" target="_blank">https://github.com/galderz/hibernate-orm/commits/t_i9x_v2</a><br>
>>>> --<br>
>>>> Galder Zamarreño<br>
>>>> Infinispan, Red Hat<br>
>>>><br>
>>>>> On 16 May 2017, at 17:06, Paul Ferraro <<a href="mailto:paul.ferraro@redhat.com" target="_blank">paul.ferraro@redhat.com</a>> wrote:<br>
>>>>><br>
>>>>> Thanks Galder. I read through the infinispan-dev thread on the<br>
>>>>> subject, but I'm not sure what was concluded regarding the eventual<br>
>>>>> home for this code.<br>
>>>>> Once the testsuite passes, is the plan to commit to hibernate master?<br>
>>>>> If so, I will likely fork these changes into a WF module (and adapt it<br>
>>>>> for Hibernate 5.1.x) so that WF12 can move to JGroups4+Infinispan9<br>
>>>>> until Hibernate6 is integrated.<br>
>>>>><br>
>>>>> Radim - one thing you mentioned on that infinispan-dev thread puzzled<br>
>>>>> me: you said that invalidation mode offers no benefits over<br>
>>>>> replication. How is that possible? Can you elaborate?<br>
>>>>><br>
>>>>> Paul<br>
>>>>><br>
>>>>> On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño <<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>> wrote:<br>
>>>>>> I'm on the move, not sure if Paul/Radim saw my replies:<br>
>>>>>><br>
>>>>>> <pferraro> galderz, rvansa: Hey guys - is there a plan for Hibernate &<br>
>>>>>> ISPN 9?<br>
>>>>>> <rvansa> pferraro: Galder has been working on that<br>
>>>>>> <rvansa> pferraro: though I haven't seen any results but a list of<br>
>>>>>> stuff that needs to be changed<br>
>>>>>> <pferraro> galderz: which Hibernate branch are you targeting?<br>
>>>>>> <rvansa> pferraro: 5.2, but there are minute differences between 5.x<br>
>>>>>> in terms of the parts that need love to get Infinispan 9 support<br>
>>>>>> *** Mode change: +v vblagoje on #infinispan by ChanServ<br>
>>>>>> (ChanServ@services.)<br>
>>>>>> <pferraro> rvansa: are you suggesting that 5.0 or 5.1 branches will be<br>
>>>>>> adapted to additionally support infinispan 9? how is that<br>
>>>>>> possible?<br>
>>>>>>> pferraro: i'm working on it as we speak...<br>
>>>>>>> pferraro: down to 16 failuresd<br>
>>>>>>> pferraro: i started a couple of months ago, but had talks/demos to<br>
>>>>>> prepare<br>
>>>>>>> pferraro: i've got back to working on it this week<br>
>>>>>> ...<br>
>>>>>>> pferraro: rvansa<br>
>>>>>>> rvansa: minute differences my ass ;p<br>
>>>>>>> pferraro: did you see my replies?<br>
>>>>>>> i got disconnected while replying...<br>
>>>>>> <pferraro> hmm - no - I didn't<br>
>>>>>> <pferraro> galderz: ^<br>
>>>>>>> pferraro: so, working on the HB + I9 integration as we speak<br>
>>>>>>> pferraro: i started a couple of months back but had talks/demos to<br>
>>>>>> prepare and had to put that aside<br>
>>>>>>> pferraro: i'm down to 16 failures<br>
>>>>>>> pferraro: serious refactoring required of the integration to get it<br>
>>>>>> to compile and the tests to pass<br>
>>>>>>> pferraro: need to switch to async interceptor stack in 2lc<br>
>>>>>> integration and get all the subtle changes right<br>
>>>>>>> pferraro: it's a painstaking job basically<br>
>>>>>>> pferraro: i'm working on<br>
>>>>>> <a href="https://github.com/galderz/hibernate-orm/tree/t_i9x_v2" rel="noreferrer" target="_blank">https://github.com/galderz/hibernate-orm/tree/t_i9x_v2</a><br>
>>>>>>> pferraro: i can't remember where i branched off, but it's a branch<br>
>>>>>> that steve had since master was focused on 5.x<br>
>>>>>>> pferraro: i've no idea when/where we'll integrate this, but one<br>
>>>>>> thing is for sure: it's nowhere near backwards compatible<br>
>>>>>>> actually, fixed one this morning, so down to 15 failures<br>
>>>>>>> pferraro: any suggestions/wishes?<br>
>>>>>>> is anyone out there? ;)<br>
>>>>>> Cheers,<br>
>>>>>> --<br>
>>>>>> Galder Zamarreño<br>
>>>>>> Infinispan, Red Hat<br>
>>>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>><br>
>>> JBoss Performance Team<br>
>>><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
</blockquote></div>