[infinispan-dev] An observation about total order and consistency
Pedro Ruivo
pruivo at gsd.inesc-id.pt
Wed Mar 7 08:28:31 EST 2012
Hi,
I think that the Total Order has the same behavior as a 2PC with <sync>
and with flag ||syncCommitPhase=false (where the prepare command is sent
synchronous and the commit command is sent asynchronous).
That failed test can be solved in a easy way: check if
syncCommitPhase==true then wait for all ACKs (send the prepare in a
synchronous way). This way, you have the guarantee that everybody saw
and applied the modifications.
Cheers,
Pedro
On 3/7/12 1:44 AM, Mircea Markus wrote:
> With total order and sync replication it is possible for the following:
>
> tm.begin()
> cache(0).put(k,v);
> tm.commit();
>
> assert cache(0).get(k).equals(v); //always passes
> assert cache(1).get(k).equals(v); //might fail!
> //..but
> eventually(cache(1).get(k).equals(v)) //this will always pass
>
> In other words, after a transaction is completed, you are only guaranteed to see its results on the originator node. On replicas the value is only eventually made available.
> Whilst this is fine for embedded caches, as in practice the replication would happen between different JVMs, this is still relevant for:
> - hotrod: a client might tx-write on a node and read from the other
> - tests
>
> Cheers
> Mircea
> --
> Mircea Markus
> twitter.com/mirceamarkus
>
> Sr. Software Engineer, Infinispan
> http://www.infinispan.org
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120307/2b05c243/attachment.html
More information about the infinispan-dev
mailing list