EJBLocalHome and EJBLocalObject

[Tom Griffith]

Hello. If somebody has a minute, I'm a little confused about passing around copies of serialized objects vs reference values as parameters and/or return values. For instance, say that I am creating a cmp entity bean using create(String a, String b) inside a home interface that extends EJBLocalHome...

What gets passed to the bean? Is it a serialized copy of both String objects or two reference values? My thought is that it would be two reference values since EJBLocalHome is extended and it's running on the same jvm.

However, If I extend EJBHome and EJBObject for the home and component interfaces (as opposed to EJBLocalHome and EJBLocalObject), and the client is still running in the same jvm, does this change anything regarding the parameters?...

I hope this is understandable. Thank you very much for reading this or whatever and for your time.
[ September 13, 2005: Message edited by: Tom Griffith ]

[Peer Reynders]

No, you are on the right track, according to the spec:

Sun Microsystems Enterprise JavaBeansTM Specification, Version 2.0

page 53
5.4 Determining the client view

Remote calls involve pass-by-value. This copy semantics provides a layer of isolation between caller and callee, and protects against the inadvertant modification of data. The client and the bean may be programmed to assume this parameter copying.

Local calls involve pass-by-reference. The client and the bean may be programmed to rely on pass-by-reference semantics. For example, a client may have a large document which it wants to pass on to the bean to modify (and the bean further passes on). In the local programming model the sharing of state is possible. On the other hand, when the bean wants to return a data structure to the client but the bean does not want the client to modify it, the bean explicitly copies the data structure before returning it, while in the remote programming model the bean does not copy because it assumes that the system will do the copy.

Because local calls involve pass-by-reference, the local client and the enterprise bean providing the local client view are collocated.

(end Quote)
So in the local (first) case the interface uses reference semantics, while in the remote (second) case the interface uses value sematics - even when running in the same JVM. It was because of the overhead of the remote interfaces that local interfaces were introduced. However, it does get confusing when the changes on a parameter object affect the original object in the local case - but not in the remote case.

Note however that a vendor-specific extension may allow the optimization of remote interfaces within the same container/JVM - though that is not part of the spec and therefore not portable.

[Ganesh Krishnan]

Hi Tom,

As Peer said, it doesn't matter where the client and the EJBObject are running on the same jvm, the call will be still REMOTE.

For ejb's using remote component interface, if you want to still make use of call-by-ref., then you may need to tune the application server to optimize the call to pass as ref rather than by-value.. if everything resides on same jvm.

This may lead to problems like portability and also you need to make sure that the state of the objects being paased by reference are maintained preoperly...

- Ganesh.
SCJP,SCBCD,SCEA,BEA Certified Weblogic Administrator.

[Roger Chung-Wee]

For ejb's using remote component interface, if you want to still make use of call-by-ref., then you may need to tune the application server to optimize the call to pass as ref rather than by-value.. if everything resides on same jvm.

Call-by-reference depends not only on the caller and callee being in the same JVM: they must both be in the same application. A server such as WebLogic Server will always use call-by-value between applications even if they are within the same JVM. This is because applications have their own classloader hierarchy, so any application class which has a definition in both classloaders will receive a ClassCastException error if you use call-by-reference between applications.

[Tom Griffith]

Thank you very much for the info everybody...