Thanks! Sanne
On 13 March 2017 at 11:50, Tristan Tarrant <ttarr...@redhat.com> wrote: > Let's make it default. The 9.0 train definitely hasn't left the station yet. > > Tristan > > On 27/02/17 12:18, Radim Vansa wrote: >> Why is that JIRA closed? I was about to suggest that a complete JIRA >> triage in Alpha -> Beta stage could help, but that wouldn't notice >> closed ones. >> >> R. >> >> On 02/27/2017 11:57 AM, Galder Zamarreño wrote: >>> We keep missing the train :( >>> >>> Enabling WSC by default is something we've discussed before (JIRA & dev >>> list), e.g. >>> >>> https://issues.jboss.org/browse/ISPN-3655 >>> >>> Cheers, >>> -- >>> Galder Zamarreño >>> Infinispan, Red Hat >>> >>>> On 24 Feb 2017, at 15:45, Dan Berindei <dan.berin...@gmail.com> wrote: >>>> >>>> I still think WSC should be enabled by default, but we probably missed >>>> the 9.0 train. >>>> >>>> I see the 8.0 discussion also included batching, i.e. hiding the WSC >>>> options and forcing batching to use optimistic locking w/out WSC >>>> (currently batching allows any locking type, but batch transactions >>>> are isolated from external transactions). That would be at odds with >>>> Sanne's suggestions in the "major version cleaning" thread, because >>>> those would require a batch to join any external transaction. >>>> >>>> Cheers >>>> Dan >>>> >>>> >>>> On Fri, Feb 24, 2017 at 3:53 PM, Radim Vansa <rva...@redhat.com> wrote: >>>>> Hi all, >>>>> >>>>> I am writing a bit too late in 9.0 cycle, but since I've found couple of >>>>> bugs [1][2] and spaces for improvement [3][4] in WSC implementation, I >>>>> was wondering about confirming the performance effect of fixes. And I am >>>>> wondering if the current defaults for transactional cache, being >>>>> READ_COMMITTED and WSC off are the best options. >>>>> >>>>> During 8.0 cycle Tristan raised a discussion [5] including WSC defaults >>>>> and I think that the general opinion was "make it default", which >>>>> requires RR isolation and simple versioning scheme. But I think that the >>>>> whole thing [6] went a bit forgotten and all that was done is [7]. >>>>> >>>>> Do we want to do this, at least using current API? (we most likely don't >>>>> want to refactor ConfigurationBuilder when CR2 is out) >>>>> >>>>> Radim >>>>> >>>>> [1] https://issues.jboss.org/browse/ISPN-7526 >>>>> [2] https://issues.jboss.org/browse/ISPN-7527 >>>>> [3] https://issues.jboss.org/browse/ISPN-7528 >>>>> [4] >>>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/container/entries/ClusteredRepeatableReadEntry.java#L30 >>>>> could be a contention point >>>>> [5] >>>>> http://infinispan.markmail.org/message/rasqqkojwdboql7y?q=write+skew+list:org%2Ejboss%2Elists%2Einfinispan-dev+order:date-backward >>>>> [6] https://issues.jboss.org/browse/ISPN-3927 >>>>> [7] https://issues.jboss.org/browse/ISPN-7507 >>>>> >>>>> -- >>>>> 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 >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > 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
