The EJB Spec requires that every Entity bean also have with it an EntityKey that is used to look up the bean and compare two EntityBean''''''s.  The EntityKey is a separate utility class that is developed along with the bean.  It generally consists of the key field(s) of the corresponding database row.  EntityKey''''''s are used as a arguments to EJB finder methods and in other places.

KyleBrown

----

Is there some good argument against using things like java.lang.Integer or java.lang.String as EntityKey when your keys are only a single field?

AndersBengtsson

-----

Yes, there are some.

One argument for using java.lang.Integer etc is that it saves some coding. (Every line of code is a potential bug!)

One argument for using special key-classes is type-safety. I've been in projects where they used Strings as keys for all entities and passed them around as arguments a lot. There was some spectacular bugs happening when people mixed the different arguments up.

Also, if you have composite keys there really isn't much of a choice.

JonTirsen

-----
As of EJB1.1 it is a custom to use int and String directly without encapsulating them into wrapper classes. You can use Integer and String as EntityKey''''''s . Or your EntityKey can be a combination of all the fields (public and persistent) in your EntityBean. This is very useful if you want have the EntityBean to represent a table with no primary keys.

-SeshKumar

-----
EntityKey''''''s are also used to compare two objects. If two EntityBean''''''s have the same EntityKey then they are equal. Its different from the reference comparing under corba where we check to see if both objects point to the same chunk of memory in a VM. Fred
-SeshKumar