[infinispan-dev] Total Order non-transactional cache

[Pierre Sutra]

Hi Pedro,

I added a few comments inline to your responses.

Cheers,
Pierre



> 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).
Indeed, in the case of full replication, returning after the local
replica applies the update is fine.
Some precautions must be taken however if, for instance, the client is
accessing the system via
HotRod in round-robin mode.

> - 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.
Sorry if I was not very clear. I was asking if an Infinispan replica
knows whether it has applied some command or not.
In the case where FLUSH is not at the top of the stack this might be
necessary between two view changes, no ?


>> - 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*.
I believe that this is not the case, as processes have to simply agree
on the set of messages they receive
in the view they are currently leaving.


> 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.
I see, but it seems to me in such a case you would need either
idempotent commands,
or that processes agree on the message to deliver before the view
changes using FLUSH.
In the latter case, I was thinking that the abstraction implemented by
JGroups is virtual synchrony [1].

|1] http://www.jgroups.org/manual/html/user-advanced.html#d0e3025
(Section 5.7)