I don't mean to open this can of worms (again), but the EJB spec does
not say that the hashCode and equals methods will be used by the
server, but rather by client code:
9.2.9 Entity bean's primary key class
The Bean Provider must specify a primary key class in the deployment
descriptor.
The primary key type must be a legal Value Type in RMI-IIOP.
The class must provide suitable implementation of the hashCode() and
equals(Object other) methods to simplify the management of the primary
keys by client code.
I made the point previously, that EJB developers should not rely on the
container using their hashCode/equals methods to determine PK identity.
Some servers may chose to not use these methods, but some other mechanism
to determine PK identity. As such, EJBs which rely on the container
to use hashCode/equals to distinguish between otherwise different PK
values (that is, EJBs using the "FatKey" idiom) will be non-portable.
<vendor>
For example, Borland AppServer uses the serialization of the PK to
determine its identity, as do a number of other J2EE compliant
products.
</vendor>
-jkw
Dan Christopherson wrote:
>
> It is anticipated that the container will use that in its cacheing
> operations.
>
> On Fri, 16 Feb 2001, sanju wrote:
>
> > Can anyone tell me why do we have to override the hashCode method in
> > PrimaryKey class though we never use it?
> > Thanks in advance
> > sanjeev
===========================================================================
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".
