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(a)redhat.com&gt; 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@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 >

On 23 May 2017, at 15:07, Galder Zamarreño <galder(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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@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 >>

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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@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(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 May 2017, at 17:56, Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: 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(a)infinispan.org&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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@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(a)redhat.com&gt; >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 25 May 2017, at 15:31, Steve Ebersole <steve(a)hibernate.org&gt; wrote: A lot to read through here so I apologize up front if I missed something... 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. 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. On Wed, May 24, 2017, 11:04 AM Galder Zamarreño <galder(a)redhat.com&gt; wrote: Adding Steve, Scott Marlow just reminded me that you've advocated for Infinispan 2LC provider to be moved to Infinispan source tree [2]. So, you might want to add your thoughts to this thread? Cheers, [2] http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20... -- Galder Zamarreño Infinispan, Red Hat > On 24 May 2017, at 17:56, Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: > > 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(a)infinispan.org&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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@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(a)redhat.com&gt; >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev