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

Reply via email to