Re: [infinispan-dev] Non-blocking state transfer (ISPN-1424)
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev