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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
