Modifying the parameter Objects passed to RMI server

[Norris Watkins]

I was wondering what will happen if the Objects passed as parameters to an
RMI call is modified by the server.
Since these objects are serialized/deserialized before the server code gets
access to the parameter objects, what the server views is only a copy of the
original object.
1. What prevents the server from calling modifiers on such objects ?
2. Will the answer for 1 above be different, if both server and client are
running under the same JVM ?
3. Is there a way in RMI to send the Class information along with the object
to the remote server ? ( So that the server does not have to have compile
time knowledge of the Class that it will handle at runtime )
4. Does JNDI use RMI ? ( If I do a lookup() for a particular object from a
client JVM, and if the object is sitting under a different JVM, how is that
the calls are being dispatched over the wire ? )
5. Can I bind() objects to JNDI, that are not implementing java.rmi.Remote
?

Thanks for reading
--nw

 

[Tony Morris]

I was wondering what will happen if the Objects passed as parameters to an
RMI call is modified by the server.
Since these objects are serialized/deserialized before the server code gets
access to the parameter objects, what the server views is only a copy of the
original object.
1. What prevents the server from calling modifiers on such objects ?

The object exists once - on the server.
If you modify that instance everyone will know about it.
The client only has a stub of the object.

2. Will the answer for 1 above be different, if both server and client are
running under the same JVM ?
No.

3. Is there a way in RMI to send the Class information along with the object
to the remote server ? ( So that the server does not have to have compile
time knowledge of the Class that it will handle at runtime )

Yes, RMI can load classes across the wire.
It will do this if the class definition is not found locally if I remember
erectly.
You have to set up an appropriate security permissions file.

4. Does JNDI use RMI ? ( If I do a lookup() for a particular object from a
client JVM, and if the object is sitting under a different JVM, how is that
the calls are being dispatched over the wire ? )

No. RMI uses JNDI. You bind objects to a JNDI directory and the client looks
them up.

5. Can I bind() objects to JNDI, that are not implementing java.rmi.Remote
?

Yes, you can bind any object to a JNDI directory.
Take a look at EJBs for a practical example.

Thanks for reading
--nw

Try this
http://java.sun.com/docs/books/tutorial/rmi/index.html

 

[Norris Watkins]

Thanks Tony ( My comments below )

The object exists once - on the server.
If you modify that instance everyone will know about it.
The client only has a stub of the object.

I was talking about ordinary objects passed as parameters to RMI methods.

Yes, RMI can load classes across the wire.
It will do this if the class definition is not found locally if I remember
erectly.
You have to set up an appropriate security permissions file.


No. RMI uses JNDI. You bind objects to a JNDI directory and the client
looks
them up.

I was talking about the internal mechanism used by JNDI. How does it handle
remote calls. ( when client is in a different JVM )

 

[Harish]

RMI provides only pass by value mechanism.
Both the server and client see the same class def(of the param) So there is
nothing preventing the server from modifying a parameter.
In case of the same JVM it is more efficient(faster) to pass the params by
ref. But I guess there are options
by which you can enforce the pass by value behavior inside the same JVM.
This obviously have an overhead of
making a copy each parameter being passed. I am not sure about this option,
just remember seeing
"pass parame by value even for in-proc calls" in some option screen
somewhere!

The idea is this: since RMI uses pass by value, u r not(should not) supposed
to modify'em.
But there is nuthing preveniting you from doing so.
So a client server program which runs fine as multiple JVM may have issues
when they are put inside the same JVM.
so we have an option to enforce the "pass-by-value" even in case of in-proc
calls.
This ofcourse will have some performance issues.

And yes, JNDI is another RMI server. And I thick, JNDI contains only Remote
objects.

 

[Tony Morris]

In case of the same JVM it is more efficient(faster) to pass the params by

ref.

All Java types are pass by value, always, at all times.

 

[Harish]

All Java types are pass by value, always, at all times.

this is getting complicated....let me explain. RMI says the params are
passed by value.
So, the changes made by an RMI server to a param will not get relflected at
the client side.
This is because the params are transfered from client process space to
server process space.
so whatever changes made by the server will not get reflected at the client
side.

If both client and server are in the same process(VM), client will see the
changes made by server
because both client and server uses the same object reference. RMI can,
instead of passing the parameter,
serialize and deserialize the param(there by creating a copy of the param)
and then pass it onto server.
so the changes made by the server won't be reflected at the client side.
this is what is expensive.
If the server is not making any changes, then the serialize/deserialize is
unnecessary....

 

[Esmond Pitt]

If both client and server are in the same process(VM), client will see the
changes made by server
because both client and server uses the same object reference. RMI can,
instead of passing the parameter,
serialize and deserialize the param(there by creating a copy of the param)
and then pass it onto server.

There is at least one implementation of RMI which conforms to this
description. However this violates the RMI specification which specifies
that non-remote objects are passed by deep copy (i.e. regardless of
whether intra- or inter-JVM RMI calls are being made). Sun's
implementation conforms to the spec, and so I believe does IBM's. You
should not rely on any other behaviour.

EJP