On 19 Feb 2014, at 17:44, Dennis Reed <der...@redhat.com> wrote: > On 02/19/2014 12:57 AM, Galder Zamarreño wrote: >> On 31 Jan 2014, at 08:32, Dennis Reed <der...@redhat.com> 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. >> I disagree :). >> >> AS could abstract that configuration detail. IOW, if all Infinispan returned >> was Futures, AS or any other client application, has the choice in their >> hands: do they wait for the future to complete or not? If they do, they’re >> SYNC, if not ASYNC. AS can still expose this and no functionality is lost. > > Yes, the functionality is still lost. Your suggestion is just to > re-implement the functionality over and over in each ISPN caller. :)
Yup, welcome to the non-blocking world. > >> What happens is that SYNC/ASYNC decision stops being a configuration option >> (bad, bad, bad) and becomes an actual programming decision Infinispan >> clients must address (good, good, good). > > This really depends on the client. For the AS session replication use > case, a config option is good, good, good. > But re-implementing the same functionality in every caller that may want > it to be a config option is bad, bad, bad. > > -Dennis > >>> -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? >>>> >>>> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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
