Hi,
I expect that using the Object hashCode, even within the same
VM, will be problematic. Two instances of such a class will not have
the same hashCode. Hence using one as a key to insert a value into
the cache, then using the other to retrieve the value will not
produce the expected results. This is true of pretty much any type
of hash table, distributed or not. Your key can not use the Object
hashCode method.
This is also also relevant to your discussion of using binary data (I
presume a byte array) in the cache. You can use an array as a hash key
in any meaningful way. However, it is perfectly reasonable to wrap the
array in an object that computes the hash from the array contents. I
know this from practical experience implementing a distributed version
of JBoss Cache.
Alex
--- On Tue, 10/13/09, Jason T. Greene <jason.greene(a)redhat.com> wrote:
From: Jason T. Greene <jason.greene(a)redhat.com>
Subject: Re: [infinispan-dev] Hash calculation in DefaultConsistentHash
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Date: Tuesday, October 13, 2009, 12:41 PM
Manik Surtani wrote:
> On 13 Oct 2009, at 15:30, Jason T. Greene wrote:
>
>> We've always had that requirement. Hes referring
to classes which do
>> not
>> define a hashCode, and thus inherit
Object.hashCode(), which
>> produces a
>> number based on the reference pointer which is
different per-vm.
>
> Sure, but for folks that don't expect to be able to
retrieve a key
> from anywhere, it should still work. But that is
a weird use case
> anyway, unless the cache is in local mode in which
case DIST doesn't
> apply.
>
Right, you can do it in local mode. His hashcode routine
would of course
still work for that, that is if you wanted to have
datacontainer alwyas
use it (probably a good idea).
--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev