<div dir="ltr"><div>Ben, I'm pretty sure it's not possible to define getKeyForAddress as returning the same type as its input key.<br><br></div><div>Let's say f1(address)(x) = getKeyForAddress(address, x)<br><br>
</div>f1(address) has to be injective for each address. So if the size of the key domain is size(K) and the number of addresses is N, the number of unique output values of getKeyForAddress is N * size(K), which is clearly not possible.<br>
<div><div><br><div>It's probably possible to define something like this instead:<br><br>PinnedKey<K> getKeyForAddress(address, key)<br><br><br></div>Even so, keeping the result key pinned to the same address after a rebalance would be tricky - probably requiring some changes to the ConsistentHash implementation. Of course, the node to which the key is pinned may also die, and I'm not sure where the keys should be located then. <br>
<br>For the existing KeyAffinityService methods it's simple: they give you a key that is currently mapped to a specific node, but they don't make any guarantees about where that key will be located in the future.<br>
<br></div><div>Speaking of which, how do you know which keys should map to which node in your application?<br><br></div><div>If the rules are simple enough, you may be able to create multiple caches, each of them with a custom ConsistentHashFactory that locates *all* the keys to the same primary node (with random backup owners).<br>
</div><div><div>
<div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers<br></div><div class="gmail_extra">Dan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 3:43 PM, cotton-ben <span dir="ltr"><<a href="mailto:ben.cotton@alumni.rutgers.edu" target="_blank">ben.cotton@alumni.rutgers.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for this reply, Mircea.<br>
<br>
Very interesting approach. By dispatching a distributed executor back to<br>
the node (node 0) that produced the pinned key affinity for the object's<br>
natural key, we could indeed do an iterative search (from node 2) to find<br>
the original 'myObject' in the pinned cache (on node 0). As you point out,<br>
however, this approach is prohibitively costly -- we are effectively doing<br>
an iterative search across nodes.<br>
<br>
Again, we see the best approach as being to use the enhancement to the Key<br>
Affinity Service API suggested in <a href="https://issues.jboss.org/browse/ISPN-3112" target="_blank">https://issues.jboss.org/browse/ISPN-3112</a>.<br>
Once<br>
<br>
*K getKeyForAddress(Address pinnedNodeAddress, K objectNaturalKey);*<br>
<br>
is provided, we will be able to proceed as simply as follows:<br>
<br>
//given that all nodes "know" that all birthday Entry(s) are pinned to Node<br>
0<br>
<br>
@t=0, from node=0, pin Entry to cache at Node 0<br>
<br>
Object pinnedKey = getKeyForAddress(getAddress("Node0"),<br>
"1962-08-10");<br>
cache.put(pinnedKey,"Ben D. Cotton III birthday");<br>
<br>
<br>
Later @t=1, from node =2, we can use the improved API (suggested in the<br>
JIRA) from a 'foreign' node without any need to do a distributed, iterative<br>
search, i.e.<br>
<br>
Object pinnedKey = getKeyForAddress(getAddress("Node0"),<br>
"1962-08-10");<br>
Object birthdayCelebrant = cache.get(pinnedKey); //return "Ben D.<br>
Cotton III birthday"<br>
<br>
<br>
Of course, for us to be able to do this, the ISPN team would have to deliver<br>
to us the API recommended in the JIRA<br>
<a href="https://issues.jboss.org/browse/ISPN-3112" target="_blank">https://issues.jboss.org/browse/ISPN-3112</a>. Don't you agree such an API<br>
enhancement would be an awesome capability improvement for ISPN users<br>
wishing to operate in a distributed fashion on pinned Caches? :-)<br>
<br>
As always, thanks to you and this forum for its fine support,<br>
Ben<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027401.html" target="_blank">http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027401.html</a><br>
<div><div>Sent from the Infinispan Developer List mailing list archive at Nabble.com.<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">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>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div>