On 31 Jan 2014, at 08:32, Dennis Reed <dereed(a)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.
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).
Chers,
-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
> galder(a)redhat.com
>
twitter.com/galderz
>
> Project Lead, Escalante
>
http://escalante.io
>
> Engineer, Infinispan
>
http://infinispan.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
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org