[infinispan-dev] Using infinispan as quorum-based nosql

[Galder Zamarreño]

On May 30, 2013, at 5:10 PM, vitalii.tymchyshyn at ubs.com wrote:

> Hello.
> 
> We are going to use Infinispan in our project as NoSQL solution. It
> performs quite well for us, but currently we've faced next problem.
> Note: We are using Infinispan 5.1.6 in SYNC_REPL mode in small cluster.
> The problem is that when any node fails, any running transactions wait
> for Jgroups to decide if it've really failed or not and rollback because
> of SuspectException after that. While we can live with a delay, we'd
> really like to skip rolling back. As for me, I actually don't see a
> reason for rollback because transactions started after leave will
> succeed. So, as for me, previously running transactions could do the
> same.

We're aware of the problem (https://issues.jboss.org/browse/ISPN-2402).

@Dan, has there been any updates on this?

> The question for is if node that left will synchronize it's state after
> merge (even if merge was done without infinispan restart). As for me, it
> should or it won't work correctly at all.

This is not in yet: https://issues.jboss.org/browse/ISPN-263

> So, I've found RpcManager's ResponseMode.SYNCHRONOUS_IGNORE_LEAVERS and
> think on switching to it for RpcManager calls that don't specify
> ResponseMode explicitly. As for me, it should do the trick. Also, I am
> going to enforce Quorum number of reponses, but that's another story.
> So, how do you think, would it work?

^ Not sure if that'll work. @Dan?

> P.S. Another Q for me, how does it work now, when SuspectException is
> thrown from CommitCommand broadcasting. Af far as I can see, commit is
> still done on some remote nodes (that are still in the cluster), but
> rolled back on local node because of this exception. Am I correct?

^ How Infinispan reacts in these situations depends a lot on the type of communications (synchronous or asynchronous) and the transaction configuration. Mircea can provide more details on this.

Cheers,

> This
> can cause inconsistencies, but we must leave with something in
> peer-to-peer world :) The only other option is to switch from write-all,
> read-local to write-quorum, read-quorum scenario that is too complex
> move for Infinispan as for me.
> 
> Best regards, Vitalii Tymchyshyn
> 
> Please visit our website at 
> http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html 
> for important disclosures and information about our e-mail 
> policies. For your protection, please do not transmit orders 
> or instructions by e-mail or include account numbers, Social 
> Security numbers, credit card numbers, passwords, or other 
> personal information.
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org