On 31 Jan 2014, at 11:59, Sanne Grinovero <sanne(a)infinispan.org> wrote:
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
Ok, this a limitation of my approach.
For such scenarios, you could maybe leave the async store option around, with a note on
when the future completes based on this option.
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 <ttarrant(a)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
>>> 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
>>
>
> _______________________________________________
> 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