[infinispan-dev] Repeatable reads and WSC as default

[Sanne Grinovero]

Thanks!

Sanne

On 13 March 2017 at 11:50, Tristan Tarrant <ttarrant at 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.berindei at 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 <rvansa at 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 <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
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev