Thx Steve for your input. Seems like everyone agrees moving to Infinispan might be best option, so I'll be sending a proposal to the list in the next few days.
Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 25 May 2017, at 15:31, Steve Ebersole <st...@hibernate.org> 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 <gal...@redhat.com> 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/2015/%23hibernate-dev.2015-08-06.log.html > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 24 May 2017, at 17:56, Paul Ferraro <paul.ferr...@redhat.com> 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 <sa...@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 <rva...@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.ferr...@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 <gal...@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@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 <rva...@redhat.com> > >>> JBoss Performance Team > >>> > >>> _______________________________________________ > >>> infinispan-dev mailing list > >>> infinispan-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
