• Post Reply Bookmark Topic Watch Topic
  • New Topic

pass by reference pitfalls

 
Graham VMead
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Could someone please outline any potential problems with using pass by reference between two colocated EJBs. We are looking into this by setting the "pass by reference" option in Websphere. Is it also true that Local Interfaces pass by reference?

I know about the consideration that if an object is passed by reference from one EJB to another, any changes performed on this object in the called EJB will be reflected in the object referenced in the calling EJB.


I have been told by an 'architect' where I work that if you pass a member variable (ie instance attribute of the calling EJB) from one EJB to another EJB (stateful) by reference, that this will cause problems in passivation.
I can't see how as it is just a reference.


TIA Graham
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer is that turning on -noLocalCopies (or using local EJBs) amounts to changing the semantics from pass-by-value to pass-by-reference. It works the way you think -- there's nothing magic here.

The canonical problem (as you've stated above -- let me get pedantic to clarify this for others) that this can cause is the following.

You pass in an object (say an Employee, having an age variable) to a session bean. The age variable is set to the integer 30. The session bean (which behaves poorly, as no good programmer would do this) changes the value of the Employee's age using employee.setAge(29).

In a remote EJB call, the employee passed in by the calling class and the one modified by the EJB are different objects, however, when using pass-by-reference, they are the same object.

So, when the calling class then examines the value of the age variable (using employee.getAge()) they get the value 29, and not the expected value (30).

Does this happen often? No. Can it happen? Yes, IF your programmers are bad programmers who modify input parameters in session beans (something we learned not to do lightly in CS 101). However, it can be just as easily caught through standard code reviews. I've not seen this cause a huge problem yet, since the practice (a) isn't that widespread and (b) is easy to catch in testing and code review.

Now, on to your stateful bean problem. If you pass off the value of an instance variable that is itself an object (like an Integer, or an Employee) then yes, you're now in the situation described above. If you pass a primitive, or an immutable object like a String, then it can't happen. Your gut feel is correct in the first place. A

lso, I can't imagine any situation where this could cause a real problem in passivation -- passivation doesn't travel links backwards, only forwards. If you serialize an object it doesn't matter who was pointing to it, it still gets serialized. When it's rematerialized later, it's a brand new object. This may mean that the other session bean (the one pointing to the old one) now has a second copy of the object (the passivated bean has a new one -- the other bean has the old one). But good grief -- if your design is so sensitive that it depends on subtleties like that, you're in bigger trouble than any of us can help.

Kyle
[ May 20, 2004: Message edited by: Kyle Brown ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!