Re: unclear about synchronization requirements in UnicasteRemoteObject

> After reading the JDK 1.2 and 1.1 RMI specs, I remain unclear about
> thread-safety in a RMI/JRMP implementation.
>
> This is my first experience with RMI...here are the facts:
>
> We have an sub-class of UnicasteRemoteObject called RMIServlet which
> implements the remote interface RMIProxy
>
> This is bound to a port 8080.
>
> It has the following global variables (only):
>
> Private ServerProxyCMPHome proxyHome = null;  // session EJB
> Private AclPolicy securityPolicy = null;
> Private SessionTrackerData sessionData = null;
> Private UserData userData= null;
>
> All other variables are local to methods.
>
> Now, my understanding is that the calls to the various remote
> interface methods are thread-safe (either because of the local
> variables or because RMI client connections are single-threaded or
> both )
>
> Q's:
>
> 1.  Is it true, then, that the only potential source of problems
> would be if two separate threads in two different methods modify one
> of the global variables?...Thus all acces to the global variables
> should be synchronized?

I'm not entirely following your question (is your "understanding"
above based on specific analysis of this particular application?).  It
would seem that some form of synchronization is required if concurrent
access of the "global variables" by different threads can occur.  As
far as RMI is concerned, concurrently received remote invocations
(from the same or different client VMs, to the same or different
remote objects, of the same or different remote methods) will
generally be dispatched concurrently (in separate threads), so remote
object implementations should be prepared for that to occur.

> 2.  One of the weird things in this implementation: when the user
> calls authenticate() on the remote object (RMIServlet) , it returns
> a new instance of the RMIServlet to the client but doesn't
> bind/rebind these new instances to any port.  What would be the
> intent of doing this?  Are there potential problems?

You mean that it doesn't bind/rebind the new instances to an RMI
registry (although they are still exported as remote objects, in this
case implicitly because their class extends UnicasteRemoteObject)?  I
would guess that that's because each one's instance state is specific
to the particular client it is returned to, so it doesn't make sense
to make them available for other clients to look up by name in the
registry.

-- Peter

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html