Is there any performance problem with calling one EJB from another EJB running in the same container?

There are two potential performance issues here, one of which has been eliminated by most (if not all) container vendors, and the other of which many container vendors have optional optimization for.

The first issue is that given naive implementations of the JNDI context objects that the beans use to look each other up, the calls might go through RMI, which involves quite a bit of overhead even within a process. Again, though most if not all container vendors optimize this right out of your way. Don't worry about this one.

The second potential issue, though, comes from the spec. The EJB specification dictates that the container copy all method parameters and return values on these calls. Here is the quote from section 18.2.3: <quote> Specifically, the EJB Container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean’s semantics. </quote> All this copying has obvious performance implications. However, most container vendors allow this behavior to be overridden for performance reasons.