Modifying the parameter Objects passed to RMI server

Discussion in 'Java' started by Norris Watkins, Dec 31, 2004.

  1. 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
    Norris Watkins, Dec 31, 2004
    #1
    1. Advertising

  2. Norris Watkins

    Tony Morris Guest

    "Norris Watkins" <> wrote in message
    news:jKiBd.5549$...
    > 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

    --
    Tony Morris
    http://xdweb.net/~dibblego/



    --
    Tony Morris
    http://xdweb.net/~dibblego/
    Tony Morris, Dec 31, 2004
    #2
    1. Advertising

  3. Thanks Tony ( My comments below )

    "Tony Morris" <> wrote in message
    news:aSiBd.97773$...
    > "Norris Watkins" <> wrote in message
    > news:jKiBd.5549$...
    >> 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.


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

    >
    >> 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.



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


    >
    >> 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
    >
    > --
    > Tony Morris
    > http://xdweb.net/~dibblego/
    >
    >
    >
    > --
    > Tony Morris
    > http://xdweb.net/~dibblego/
    >
    >
    >
    Norris Watkins, Dec 31, 2004
    #3
  4. Norris Watkins

    Harish Guest

    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.

    "Norris Watkins" <> wrote in message
    news:jKiBd.5549$...
    >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
    >
    Harish, Jan 2, 2005
    #4
  5. Norris Watkins

    Tony Morris Guest

    > 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.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
    Tony Morris, Jan 2, 2005
    #5
  6. Norris Watkins

    Harish Guest

    "Tony Morris" <> wrote in message
    news:Gq%Bd.100763$...
    >> 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.
    >

    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....

    > --
    > Tony Morris
    > http://xdweb.net/~dibblego/
    >
    >
    >
    Harish, Jan 3, 2005
    #6
  7. Norris Watkins

    Esmond Pitt Guest

    Harish wrote:
    > 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
    Esmond Pitt, Jan 3, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dee
    Replies:
    9
    Views:
    493
    Joseph Byrns
    Apr 15, 2005
  2. Buu Nguyen

    RMI, JINI or RMI/IIOP

    Buu Nguyen, Aug 25, 2004, in forum: Java
    Replies:
    1
    Views:
    551
    Sudsy
    Aug 25, 2004
  3. Anand
    Replies:
    2
    Views:
    888
    Anand
    Sep 11, 2003
  4. Scott Taylor

    malloc modifying a passed string

    Scott Taylor, Jul 28, 2005, in forum: C Programming
    Replies:
    4
    Views:
    324
    CBFalconer
    Jul 28, 2005
  5. soren625
    Replies:
    10
    Views:
    229
    Kevin Collins
    Dec 28, 2005
Loading...

Share This Page