[infinispan-dev] Total Order non-transactional cache

Bela Ban bban at redhat.com
Wed Nov 19 11:17:31 EST 2014



On 11/18/2014 11:53 AM, Pedro Ruivo wrote:
> Hi Pierre,
>
> Thanks for the feedback.
>
> My comments are inline.
>
> Cheers,
> Pedro
>
> On 11/17/2014 12:22 PM, Pierre Sutra wrote:
>> Hello Pedro,
>>
>> I read your design page with interest, and formulated a few
>> remarks/questions below. Despite I do not know in details the internals,
>> I Hope that they might be useful.
>>
>> Cheers,
>> Pierre
>>
>> - It is unclear to me how the protocol execute reads, in particular
>> regarding causality. If a reader waits for a single replica to answer,
>> in case every write requires all replicas to answer, this is fine.
>> However, it seems that a writer can return as soon as a single replica
>> returns an acknowledgement. In such a case, it might be the case that a
>> reader do not see its own modifications, if it retrieves data from a
>> replica that did not apply the modifications yet.
>
> You're right. The writer must wait for all the replies except if the
> cache is full replicated (in this case, it can wait for the self-deliver).
>
>>
>> - Do you ensure impotency of commands inside ISPN ? In my understanding,
>> it is necessary when switching from a view v1 to a view v2, as commands
>> delivered at the end of v1 might be already executed.
>
> I'm lost here. can you be clear? are you talking about JGroups view or
> Infinispan cache topology?
>
> On the latter matters and it will delivered the cache topology changes
> in total order. So, everybody receives the same order of events.
>
>>
>> - I would call your replication protocol "virtual synchrony based"
>> instead, as it is relying on the virtual synchrony abstraction provided
>> by JGroups.
>
> I don't think so. If I recall correctly, virtual synchrony ensures that
> if a message is sent in view *v* then it is delivered in view *v*.

Are you using virtual synchrony at all ? IIRC there's no FLUSH protocol 
in the default configs. TBH, I don't recommend this anyway.


> First, that cases is not necessary since we retry the commands received
> in different topologies. Second, the protocol relies on the order in
> which the operations are delivered.
>
>>
>>
>> On 10. 11. 14 15:49, Pedro Ruivo wrote:
>>> Hi,
>>>
>>> FYI, I've just created a design page:
>>> https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transactional-Cache
>>>
>>> My plan is to implement it in 7.1 release.
>>>
>>> Feel free to comment.
>>>
>>> Cheers,
>>> Pedro
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss


More information about the infinispan-dev mailing list