I'm not sure this is valid behavior, but I can't find anything that applies explicitly
to the method return values. This EJB 1.1 spec section on argument values clearly
states that passing method arguments by reference is not allowed so I don't
know why returning a reference should be valid:
<quote>
18.2.3 Argument passing semantics
The enterprise bean's home and remote interfaces
are remote interfaces for Java RMI. The Container
must ensure the semantics for passing arguments
conform to Java RMI. Non-remote objects must be
passed by value.
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.
</quote>
----- Original Message -----
From: "toby cabot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 8:31 AM
Subject: [JBoss-user] diff in behavior between server-side and client-side
> Folks,
>
> I just noticed the following behavior and wonder if there are preferred
> patterns for dealing with it. I've got an entity bean which can
> presumably be accessed by remote client-side code (e.g. in another VM)
> or by session beans running in the jboss server VM. Let's say the
> entity bean has some code like so:
>
> private Money moola;
>
> /**
> * @remote-method
> */
> Money getMoney() {
> return moola;
> }
>
> I noticed that the remote client code gets a copy of moola but the
> server-side session bean gets a reference to the member itself (and can
> thus change it). This makes sense but it does mean that the behavior is
> different for in-VM client code and remote client code. Is this
> "standard" EJB behavior? One approach to trade some efficiency for
> safety would be as follows:
>
> Money getMoney() {
> return new Money( moola);
> }
>
> This way the clients would be unable to modify the private member even
> if they were running in the same VM. Are there other approaches?
>
> TIA,
> Toby Cabot
>
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
