Generally I like the systems designed with SYNC_DIST + async shared cachestore.
It's probably the best setup we can offer: - you need a shared cachestore for persistence consistency - using SYNC distribution to other replicas provides a fairly decent resilience - if your cachestore needs to be updated in sync, your write performance will be limited by the cachestore performance: this prevents you to use Infinispan to buffer, absorbing write spikes, and reducing write latency But I agree we should investigate on removing duplicate "asynchronizations" where they are not needed, there might be some opportunities to remove thread switching and blocking. On 31 January 2014 10:48, Tristan Tarrant <ttarr...@redhat.com> wrote: > Couldn't this be handled higher up in our implementatoin then ? > > If I enable an async mode, all puts / gets become putAsync/getAsync > transparently to both the application and to the state transfer. > > Tristan > > On 01/31/2014 08:32 AM, Dennis Reed wrote: >> It would be a loss of functionality. >> >> As a common example, the AS web session replication cache is configured >> for ASYNC by default, for performance reasons. >> But it can be changed to SYNC to guarantee that when the request >> finishes that the session was replicated. >> >> That wouldn't be possible if you could no longer switch between >> ASYNC/SYNC with just a configuration change. >> >> -Dennis >> >> On 01/31/2014 01:08 AM, Galder Zamarreño wrote: >>> Hi all, >>> >>> The following came to my mind yesterday: I think we should ditch ASYNC >>> modes for DIST/REPL/INV and our async cache store functionality. >>> >>> Instead, whoever wants to store something asyncronously should use >>> asynchronous methods, i.e. call putAsync. So, this would mean that when you >>> call put(), it's always sync. This would reduce the complexity and >>> configuration of our code base, without affecting our functionality, and it >>> would make things more logical IMO. >>> >>> WDYT? >>> >>> Cheers, >>> -- >>> Galder Zamarreño >>> gal...@redhat.com >>> twitter.com/galderz >>> >>> Project Lead, Escalante >>> http://escalante.io >>> >>> Engineer, Infinispan >>> http://infinispan.org >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
