Hi:

I have been told that it is bad practice for one entity bean to access another entity bean. On the other hand, Enterprise JavaBeans by Monson-Haefel and the Sun Pet Store Application both give examples of one entity bean (e.g., order) containing a key for another entity bean (e.g., account), and then having a method (e.g., getAccount())that accesses the second entity bean via its home interface.

Are there really issues (e.g., performance issues) associated with one entity bean accessing another one? If so, could someone please explain the issues? Thanks.

--Laurel

i think if we wrap table to Entity bean.
Can we look Entity bean -> Table?

There are many tables that have foriegn key relationship between table. The same as relationship between Entity bean.

I make that decision based on my deployment model. If two entities are going to be deployed together (same jar) then a allow them to access one another. If they are going to be deployed separately (different jar) then one enitity should access the other via a stateless session ejb. Do what makes sense.

JKT

What is the underlying reasoning for letting the depoyment model determine whether one entity bean should access another entity bean?

By using the term "deployment model", I was not refering to the Unified process Deployment model. Let me restate my previous comment:

I choose if entities can access on another based on if they are part of the same "Application". In my case, I deploy the ejb's of an application together in the same jar. For any ejb outside an application, they must access entities through a boundry stateless session bean. My reason for doing this is an application may have significant changes in entity definition, however, my stateless boundry will alway provide the same interface. This prevents changes in one "application" from craeting coding task in another. This is very important for me because I am developing some common "Application General" components.

Thanks. That makes sense.