[infinispan-dev] Repeatable reads and WSC as default

Tristan Tarrant ttarrant at redhat.com
Mon Mar 13 07:50:47 EDT 2017


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


More information about the infinispan-dev mailing list