[infinispan-dev] Repeatable reads and WSC as default

Radim Vansa rvansa at redhat.com
Mon Feb 27 06:18:51 EST 2017


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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team



More information about the infinispan-dev mailing list