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

[vitalii.tymchyshyn at ubs.com]

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.
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.
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?

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? 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.