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. :) > 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