Gene Chuang wrote:
> Jonathan, you said that Inprise implements hashing by byte-shifting the
> least and most significant digits of the longs, and in effect throwing away
> the middle. What if in my particular business arcitecture the middle digits
> ARE the most significant? I think this further shows that a vendor cannot
> possibly predict what is the "optimimum" solution for the bean architecture!
Gene,
I don't think I said that, as it is untrue. What we do is
use a GIOP serialization of the object, and then do the
following:
public int hashCode() {
if(!_hashCodeComputed) {
for(int i = 0; i < _bytes.length; i++) {
_hashCode =
(_hashCode << 8) & 0xffffff00 |
(_hashCode >> 24) & 0x000000ff;
_hashCode += _bytes[i];
}
_hashCodeComputed = true;
}
return _hashCode;
}
This uses all bytes from the serialization equivalently.
Of course, serialization can be expensive. But this is one
of the reasons we do things this way. As I said, I suspect
it is a common thing to embed the primary key in the EJBObject
reference. Thus, when a request comes in over the wire for
an entity bean, the primary key is already serialized in the
object reference. Thus, the fact that we use the serialized
version instead of the actual object is, in fact, faster than
having to read the object in via serialization just to use
its equals() and hashCode() methods.
-jkw
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
