• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to understand Passed by Reference or Copy of Value for Local or Remote Interface?

 
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ranch Buddies,
How to understand Passed by Reference or Copy of Value in a method of a bean class? If my passed param type is String, does it may any diff? If the passed param type is myClass which is RMI/IIOP compatible, how to may the myClass type as passed by Reference or passed by Copy of value?
 
Ranch Hand
Posts: 275
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure I understand your question, but I'll take a stab at it. Let's talk about only the remote scenario to start with. It shouldn't matter what the object is (String, myClass, etc), as long as it's serializable (etc) and the server has the ability to unmarshall it. Say the remote client calls a method on the component interface that has a parameter of myClass. Before the method runs, there exists two objects, one on the heap of the remote, and one on the heap of the server. Each has a reference to their own object. The server and client both should know that the other guy is not going to be mucking-about with the myClass instance that "I" have, as we sometimes do in the local scenario. When local, I will sometimes pass a reference to the myClass instance over to somebody who changes the myClass instance. When continue on, I'm thinking that the myClass has been changed. This will NOT happen in the remote scenario.
--Dale--
 
Alibabra Sanjie
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, but still not get it.
Let me rephase the question. If a method in a bean class has a reference type param or return, we should code the method differently according to the client view (interfaces) is local or remote, and we are passing the param or return will be by reference or by values. My question is how to code differently, or what is the difference?
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The local interfaces differ to the remote interfaces.
The EJBLocalHome interface does not have the getEJBMetaData(), getHomeHandle() and remove(Handle h) methods of the EJBHome interface.
The EJBLocalObject interface does not have the getHandle() method of the EJBObject interface.
When coding your local client interfaces, you would not declare RemoteException for any business methods in the component interface, nor would there be any need for the return types to be RMI-IIOP compliant. Also, in the local home interface, the create() method would not declare RemoteException (but would still have to declare CreateException). This method must, of course, return the local component interface.
Is this the kind of information that you are seeking?
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alibabra Sanjie:
Thanks, but still not get it.
Let me rephase the question. If a method in a bean class has a reference type param or return, we should code the method differently according to the client view (interfaces) is local or remote, and we are passing the param or return will be by reference or by values. My question is how to code differently, or what is the difference?


For local client view,
The param/return values of the methods in the bean class follow the normal Java Programming rule, i.e. object is passed by reference. During coding, you don't have to do any "special things" to the reference type param/return.
For remote client view,
The param/return values of the methods in the bean class must be one of these:
* Primitves
* Serializable objects
* An array or collection of primitives or Serializable objects
* A remote object
For Serializable objects, the return/param object must implement java.io.Serializable. And it's passed by value, meaning a new object is created on the client side. This object is identical to the one on the remote side. Any changes make to the object on the client side will NOT affect the one on the remote side.
For remote objects, the return/param object must implement java.rmi.Remote. The stub of the object is sent to the client side. Any changes make to the client side will affect the one on the remote side.
For more info, refer to "Mastering Enterprise JavaBeans" by Ed Roman on pg 491. Also chapter 2 of HF EJB.
Hope it'll help
Joyce
 
Alibabra Sanjie
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, if the client is local, my method return should be a reference, just like a normal Java return a reference. But if the client is remote, my method return should be a copy of value (assuming the return type is RMI/IIOP), do I have to do anything to make the reference to be a copy of value and return to the remote client?
[ April 12, 2004: Message edited by: Alibabra Sanjie ]
 
Joyce Lee
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alibabra Sanjie:
[QB]Ok, if the client is local, my method return should be a reference, just like a normal Java return a reference. But if the client is remote, my method return should be a copy of value (assuming the return type is RMI/IIOP), do I have to do anything to make the reference to be a copy of value and return to the remote client?


To return a copy of the object, the return/param object must be serializable. Primitives and String are automatically serializable since they implements Serializable (refer to Java API). If you create a new class A and you want to return this object A to the remote client, class A must implement java.io.Serializable.
class A implements java.io.Serializable {
....
}
When client receives the return object and modifies the values of instance variables, the changes will not affect the one on the remote side.
Joyce
 
Alibabra Sanjie
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
At the my first posted question, I said:

"...myClass which is RMI/IIOP compatible..."

That meant what you are trying to explain. I guess if the return type is RMI/IIOP, I don't have to do anything and simply return the reference. Right?!
 
Joyce Lee
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alibabra Sanjie:
At the my first posted question, I said: That meant what you are trying to explain. I guess if the return type is RMI/IIOP, I don't have to do anything and simply return the reference. Right?!


RMI/IIOP is a not type but a mechanism for performing networking. If the return/arg is a legal type for RMI/IIOP, you don't have to do anything. And if it is not, you have to implement Serializable.
Joyce
 
Alibabra Sanjie
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"...Don't have to do anything" Simple is that! Thanks
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But you have to be more careful with local EJBs. If client get an object from an EJB and modifies a variable inside that object that variable will also be changed on EJB side. With remote EJB you don't have to worry about that. So your client code might be different depending if it is a local or remote client.
 
Alibabra Sanjie
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

But you have to be more careful with local EJBs. If client get an object from an EJB and modifies a variable inside that object that variable will also be changed on EJB side. With remote EJB you don't have to worry about that. So your client code might be different depending if it is a local or remote client.


Victor Larr, can you explain a little bit more detail or give a simple example. Maybe you have the answer I am looking for. Thank you in advance.
 
Victor Larr
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Look at the TransferObject pattern: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
Using this pattern only make sense for remote EJB. This pattern
"may Introduce Stale Transfer Objects
Adopting the Updatable Transfer Objects Strategy allows the client to perform modifications on the local copy of the Transfer Object. Once the modifications are completed, the client can invoke the entity's setData() method and pass the modified Transfer Object to the entity. The entity receives the modifications and merges the new (modified) values with its attributes. However, there may be a problem with stale Transfer Objects. The entity updates its values, but it is unaware of other clients that may have previously requested the same Transfer Object. These clients may be holding in their local cache Transfer Object instances that no longer reflect the current copy of the entity's data. Because the entity is not aware of these clients, it is not possible to propagate the update to the stale Transfer Objects held by other clients." There is no such danger with local EJB. So the code is affected if client is local or remote.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic