Erik, Dan is correct that playing with hash codes is not the correct solution. ISPN-312 is the correct approach. Pete has been working on a first-cut of this and it should make 5.0.0.CR3. (Understood that release candidates aren't the place to add new features, but we're adding it as a "preview", just to get feedback on the API and impl.)
Have a look at the proposed API on https://issues.jboss.org/browse/ISPN-312 and let us know if it works for you. Cheers Manik On 13 May 2011, at 18:28, Erik Salter wrote: > 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-boun...@lists.jboss.org > [mailto:infinispan-dev-boun...@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 <esal...@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-boun...@lists.jboss.org >> [mailto:infinispan-dev-boun...@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 >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
