By default, the Application Server uses pass-by-value semantics for calling the remote interface of a bean, even if it is co-located. This can be expensive, since clients using pass-by-value semantics must copy arguments before passing them to the EJB component.
However, local clients can use pass-by-reference semantics and thus the local and remote interfaces can share the passed objects. But this means that the argument objects must be implemented properly, so that they are shareable. In general, it is more efficient to use pass-by-reference semantics when possible.
Using the remote and local interfaces appropriately means that clients can access EJB components efficiently. That is, local clients use the local interface with pass-by-reference semantics, while remote clients use the remote interface with pass-by-value semantics.
However, in some instances it might not be possible to use the local interface, for example when:
The application predates the EJB 2.0 specification and was written without any local interfaces.
There are bean-to-bean calls and the client beans are written without making any co-location assumptions about the called beans.
For these cases, the Application Server provides a pass-by-reference option that clients can use to pass arguments by reference to the remote interface of a co-located EJB component.
You can specify the pass-by-reference option for an entire application or a single EJB component. When specified at the application level, all beans in the application use pass-by-reference semantics when passing arguments to their remote interfaces. When specified at the bean level, all calls to the remote interface of the bean use pass-by-reference semantics. See Value Added Features in Sun Java System Application Server 9.1 Developer’s Guide for more details about the pass-by-reference flag.
To specify that an EJB component will use pass by reference semantics, use the following tag in the sun-ejb-jar.xml deployment descriptor:
This avoids copying arguments when the EJB component’s methods are invoked and avoids copying results when methods return. However, problems will arise if the data is modified by another source during the invocation.