[infinispan-dev] Total Order non-transactional cache
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.
> 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.
>> - 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:
>>> FYI, I've just created a design page:
>>> My plan is to implement it in 7.1 release.
>>> Feel free to comment.
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
Lead JGroups / Clustering Team
More information about the infinispan-dev