[infinispan-dev] Non-blocking state transfer (ISPN-1424)

[Dan Berindei]

Sorry for making you nervous Erik, but if I remember correctly you're
using synchronous caches so these paragraphs should not apply to your
use case.

In asynchronous caches there is always the possibility of
inconsistency, because different owners can receive the transactions
in a different order (and the transactions are always 1PC). So this is
really nothing new, I just thought I could close one window of
inconsistency during view changes and I realized that it's not that
easy.

In sync caches with async commit, the commit RPC synchronous, but on a
background thread, so we are able to retry the command on the new
owners.

There is one scenario open to inconsistencies for sync caches: when
the originator dies before retrying the command on the new nodes.
Enabling recovery will fix this, but I think forwarding from the old
owners could be a more lightweight solution (at the cost of extra
complexity, of course).

Cheers
Dan


On Thu, Mar 15, 2012 at 3:16 PM, Erik Salter <an1310 at hotmail.com> wrote:
> Hi Dan,
>
> This statement makes me nervous.  Would we still have inconsistencies in a
> transactional context as well?
>
> "We didn't discuss this in London, I added it afterwards as I realized
> that without forwarding we'll be losing data. I didn't realize at the
> time, however, that the current design has the same problem.
>
> I think I see a problem with my request forwarding plan: the requests
> will have a different source, so JGroups will not ensure an ordering
> between them and the originator's subsequent requests. This means
> we'll have inconsistencies anyway, so perhaps it would be better if we
> stuck to the current design's limitations and remove the requirement
> for old targets to forward commands to new ones."
>
> Regards,
>
> Erik
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev