Why not even for 4.1 and 4.2 and let people know the risk of data inconsistency should they turn it on? On 2010-08-17, at 5:37 AM, Galder Zamarreño wrote: > Hi, > > I'm in the middle of writing a wiki on the different asynchronous options, including the effect they have on reordering, and I was considering the following: > > For 5.0, we should make async marshalling should be turned off by default. When it's on, there's risk of reordering and when it's off, async is slower. I'd rather have a slower solution by default rather than one that can cause data consistency issues in applications that make multiple modifications on the same key. If you only make one modification per k/v, you're fine, otherwise the reordering risk is there. > > Thoughts? > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Vladimir Blagojevic JBoss Clustering Team JBoss, by Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

+1 the sooner the better On 17 Aug 2010, at 11:02, Manik Surtani wrote: > Yeah I agree with Vladimir. > > On 17 Aug 2010, at 10:47, Vladimir Blagojevic wrote: > >> Why not even for 4.1 and 4.2 and let people know the risk of data inconsistency should they turn it on? >> On 2010-08-17, at 5:37 AM, Galder Zamarreño wrote: >> >>> Hi, >>> >>> I'm in the middle of writing a wiki on the different asynchronous options, including the effect they have on reordering, and I was considering the following: >>> >>> For 5.0, we should make async marshalling should be turned off by default. When it's on, there's risk of reordering and when it's off, async is slower. I'd rather have a slower solution by default rather than one that can cause data consistency issues in applications that make multiple modifications on the same key. If you only make one modification per k/v, you're fine, otherwise the reordering risk is there. >>> >>> Thoughts? >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Vladimir Blagojevic >> JBoss Clustering Team >> JBoss, by Red Hat >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev