[infinispan-dev] KeyAffinityService

cotton-ben ben.cotton at ALUMNI.RUTGERS.EDU
Fri Jun 14 10:46:35 EDT 2013



/It's probably possible to define something like this instead:

PinnedKey<K> getKeyForAddress(address, key)
/

This is fine.  Do it this way.

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

But, shouldn't some combination of my usage of the ISPN Grouper<T> and the
ISPN KeyAffintyService capabilities cover me?   In my understanding, the
Grouper capability can allow me to "group" my keys to a specific node
(however node identity is anonymous).  Grouper capability's ambition is to
transparently survive topology changes of nodes participating in my grid. 
In my understanding, the KAS capability can allow me to "pin" my keys to a
specific node (by node identity).   A potetnailly great tutorial document
for ISPN users might be "How to harmoniously use the ISPN Grouper and ISP
KeyAffinityService Capabilities".  How to use these 2 meritorious capabilies
together (and in harmony) is still unclear to me.

/Speaking of which, how do you know which keys should map to which node in
your application?/

We just know.  :-)   Seriously, we do have a mechanism for resolving
pinnedKey identity to Node identity custody.

/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)./

Very true.  But we don't think that is as nice as extending the API in the
way recommend.  To be blunt, we could just do something as simple as this:

@t=0, from node=0, pin Entry to cache at Node 0

      Object pinnedKey = getKeyForAddress(getAddress("Node0"),"1962-08-10");
      globalReplicatedPinnedKeyCache.put("1962-08-10", pinnedKey); //cache
the pinnedKeys globally
      pinnedCache.put(pinnedKey,"Ben D. Cotton III birthday");

Later @t=1, from node =2

       Object pinnedKey =  globalReplicatedPinnedKeyCache.get("1962-08-10");
       Object birthdayCelebrant = pinnedCache.get(pinnedKey);  //return "Ben
D. Cotton III birthday"

But that is effectively forcing us to do 2 explicit Cache<K,V>#get()
operations in application code.  First to get the pinnedKey (given the
naturalKey).  Second to get the pinnedValue (given the pinnedKey).  Not
preferred -- but DOABLE, FOR SURE.

What do you think?  Just for the "niceness" of it, do you think  we might be
able to have the API suggested at https://issues.jboss.org/browse/ISPN-3112  
?





--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027403.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.


More information about the infinispan-dev mailing list