Hi Dan,
I don't necessarily care about which server it's on, as long as the keys for my
set of caches all remain collocated. I understand they will all end up in the same
bucket, but for one hash code, that's at most 200 keys. I must acquire a lock for a
subset of them during a transaction -- so I make liberal use of the
"eagerLockSingleNode" option and redirecting my calling application to execute a
transaction on the local node. Acquiring cluster-wide locks is an absolute throughput
killer.
I took a look at the KeyAffinityService a while ago (when it came out) and quickly
realized it would not be suitable for my purposes. I was wondering if ISPN-977 would
allow me to use it. But you're right. What I ultimately want is ISPN-312.
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Dan Berindei
Sent: Friday, May 13, 2011 12:58 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Generated keys affected by rehash Was:
https://issues.jboss.org/browse/ISPN-977
On Fri, May 13, 2011 at 6:38 PM, Erik Salter <esalter(a)bnivideo.com> wrote:
Yes, collocation of all keys is a large concern of my
application(s).
Currently, I can handle keys I'm in control of (like database-generated keys), where
I can play around with the hash code. What I would love to do is collocate that data
with keys I can't control (like UUIDs) so that all cache operations can be done in the
same transaction on the data owner's node.
By playing around with the hash code do you mean you set the hashcode for all the keys you
want on a certain server to the same value? I imagine that would degrade performance quite
a bit, because we have HashMaps everywhere and your keys will always end up in the same
hash bucket.
ISPN-312 seems to me like a much better fit for your use case than the KeyAffinityService.
Even if you added a listener to change your keys when the topology changes, that would
mean on a rehash the keys could get moved to the new server and then back to the old
server, whereas with ISPN-312 they will either all stay on the old node or they will all
move to the new node.
Cheers
Dan
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Manik
Surtani
Sent: Friday, May 13, 2011 5:25 AM
To: infinispan -Dev List
Subject: [infinispan-dev] Generated keys affected by rehash Was:
https://issues.jboss.org/browse/ISPN-977
On 11 May 2011, at 18:47, Erik Salter wrote:
> Wouldn't any rehash affect the locality of these generated keys, or am I missing
something?
It would. And hence ISPN-977, to address that. Or is your concern keys already
generated before the rehash? The latter would certainly be a problem. Perhaps, if this
was important to the application, on detecting a change in topology, re-generate keys and
move data around? For other apps, move the "session" to the appropriate node?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
The information contained in this message is legally privileged and confidential, and is
intended for the individual or entity to whom it is addressed (or their designee). If this
message is read by anyone other than the intended recipient, please be advised that
distribution of this message, in any form, is strictly prohibited. If you have received
this message in error, please notify the sender immediately and delete or destroy all
copies of this message.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
The information contained in this message is legally privileged and confidential, and is
intended for the individual or entity to whom it is addressed (or their designee). If this
message is read by anyone other than the intended recipient, please be advised that
distribution of this message, in any form, is strictly prohibited. If you have received
this message in error, please notify the sender immediately and delete or destroy all
copies of this message.