File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Distributed Java and the fly likes RMI Implementation Questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Make it so: Java DB Connections & Transactions this week in the JDBC forum!
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "RMI Implementation Questions" Watch "RMI Implementation Questions" New topic

RMI Implementation Questions

David Sica
Ranch Hand

Joined: Jan 09, 2002
Posts: 39
Although I have a RMI solution in place and working I'm new to the RMI implementation. I'm trying to understand some of the basic functionality of the RMI server. I have two questions related to my implementation:
1) When I call the RMI server from my client I receive a server interface object as follows:

This is a call to my RMI server whose main method is as follows:

My question is whether I am receiving a unique instantiation of the RMI server object or just another reference to one common object instantiation? In other words if I modify data in the remote object I have a reference to, will it be modified for all other client references? If I do have just one object instantiation for my RMI server how do I modify my implementation to obtain a unique object instantiation for each client request?
2) I need to have my RMI server uptime to be near 100%. Is there a "preferred" implementation to guarantee that my rmiregistry and RMI server binding are always "active" on the Solaris server I'm running the RMI server from? Right now I've just written a couple cron shell scripts to check and see if the appropriate processes are running. If not, I restart them.
I realize this is a lengthy post so thanks in advance for reading and replying,
Michael Ernest
High Plains Drifter

Joined: Oct 25, 2000
Posts: 7292

Hi David -
The easiest way to generate a unique object for each client is to provide a factory method through the stub. That is, your stub could include a method that returns a unique instance of the thing you want. Have your service interface support something like this:

Make sure of course that Widget is Serializable and Remote too, but that will do the trick.
To look at 100% uptime, your real constraints are not only the process running the JVM, but the reliability of the overall machine. So the pressure's off -- if you're only worried about the server.
But let's say you can get that kind of uptime secured. After a while, your performance guy comes around and says that JVM running your RMI server sucks up a lot of cycles and memory, even when it's idle. Then you want to look at the Activation framework. Activation allows you to run a daemon service on your system that will wake up a server side object when it's needed, rather than make it run all the time. Worth a look!

Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
I agree. Here's the link:
subject: RMI Implementation Questions
It's not a secret anymore!