I&#39;d keep it as it is, by making promises about preserving the callable state you&#39;re opening a lot of edge cases that you need to document. You have to also specify when the state is not preserved: if the target leaves the cluster, if there is a replication timeout, if there is a problem with serialization of the intermediate state, and so on...<br>
<br>Besides, I don&#39;t think this feature would interact with transactions very well, because the Callable would be reading values from the cache in one transaction (on the original target) and using the same values in a different transaction (on the failover target) - with no consistency guarantees.<br>
<br>Cheers<br>Dan<br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 22, 2012 at 6:30 PM, Vladimir Blagojevic <span dir="ltr">&lt;<a href="mailto:vblagoje@redhat.com" target="_blank">vblagoje@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey guys,<br>
<br>
As Anna and I were working on failover tests we discovered one<br>
peculiarity - state of Callable is not preserved as we send it to<br>
various nodes for execution. I am not 100% this is important but it<br>
might be for some clients. As things stand right now we always failover<br>
to different nodes from master node. Every time Callables fails the call<br>
unwinds immediately back to originating node and originating node sends<br>
callable to another node. Fairly straight forward and expected. However,<br>
for repeated executions, we send fresh &quot;originating&quot; copy of Callable,<br>
in virgin state as it was submitted to dist.exec to begin with. In order<br>
to preserve state we would have to serialize back state from failed node<br>
and use that Callable state instead of virgin copy.<br>
<br>
What do you think? Is this state preservation a deal breaker? Or should<br>
we postpone it for next release?<br>
<br>
Regards,<br>
Vladimir<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div><br></div>